[Migrated] Move Output vars to return position (was: Storage class inference interface)

Issue automatically imported from old repo: https://github.com/EmbarkStudios/rust-gpu/issues/416
Old labels: mcp: accepted
Originally creatd by khyperia on 2021-02-11T13:41:36Z

Storage class inference is now a thing as of #300/#414. This details the design for the interface system taking advantage of inference, pointing out all the rules of how storage classes are specified in entry points.

There are a handful of ways of specifying a storage class:

1. direct attribute: fn main(#[spirv(input)] x: &f32). This uses the current list of storage classes.
2. via builtin: fn main(#[spirv(position)] x: &Vector3) (inferred as input). This uses the current list of builtins (a table is needed to map builtin to storage class, I think some are input, some are output, and there may be others)
3. via image: fn main(x: &Image2d) (inferred as uniform_constant). I thiiink images are always uniform_constant and not uniform, but I'm not sure.
4. unspecified future inference rules that we haven't discovered yet (the spec is light on what goes in what storage class), suggestions are welcome

If exactly one of these rules matches, then use the storage class it specifies.

If more than one of these rules matches, and they all compute the same storage class, emit a warning (e.g. #[spirv(position, input)], warn on input and say it's redundant). If more than one of these rules matches, and they compute different storage classes, emit an error.

If none of these rules matches, then we have an open design question. The options here are a trade-off between catching user errors that may be difficult to diagnose/guiding users with explicit syntax suggestions, and not annoying people with overly explicit syntax that takes a while to type out and read.

1. fn main(x: &f32) -> is this an error, or does it default to input? (or something else)
2. fn main(x: &Struct) -> is this an error, does it default to input, or does it default to uniform? (or something else)
3. fn main(x: &mut f32) -> is this an error, or does it default to output? (or something else)

For 2, I don't know if it's valid to have a struct (or any other non-scalar) be an input/output variable, more research is needed.

An alternative is to keep the current system of Input<T> and friends. We would remove the .load() and .store() methods entirely, and implement Deref/DerefMut (when applicable) for them. I much prefer the readability, recognizability, and usability of using plain references, but I understand others don't feel the same way~

Start by reviewing the storage-class inference work referenced in #300 and #414, along with the current Input and related interface described in the issue. Resolve the open inference and defaulting rules, then define the interface change and validation for conflicting or redundant storage-class annotations.