Maybe Naga IR should include unresolved identifiers and applications

[jimblandy]

(I'm not sure about this at all, I just wanted to get some thoughts down. "Epistemic status: daydreaming")

Loosening up naga::Module to allow "unresolved" types, functions, and global variables might

1. simplify the WGSL front end,
2. make the WGSL front end faster, and
3. make Naga more useful for experimentation like Compile with context #5791.

The idea would be to add new variants to TypeInner, Expression, and so on representing identifiers whose definitions we don't know yet, just strings. Validation would forbid these from being passed to backends, so that they wouldn't need to do more than ignore them. But these variants' presence would let people write much more interesting things that run prior to validation, including expermental stuff like #5791 (see #5791 (comment)).

If I recall correctly, the main reason the WGSL front end has an internal AST type, front::wgsl::parse::ast::TranslationUnit, that is then lowered to a Module by front::wgsl::lower, is that WGSL allows identifiers to be used before they're defined. This means that when the compiler sees an expression like x(y, z), it doesn't know whether that's:

• a call to a function named x,
• a construction of a struct type named x that has two members, or
• a construction of a vec, because x is a type alias for vec2<f32>.

These are all represented quite differently in Module, so we have to wait until we have processed the entire source and have all definitions in hand before we can decide what Naga IR to produce for x(y, z).

It seems almost inescapable that a WGSL front end should have two passes like this. But if the first pass were able to produce Naga IR directly, using these "unresolved" variants, then resolution could simply be a matter of patching up references, following through on details like struct member indices in AccessIndex expressions, and generally replacing loose IR with something more specific. This should be much faster than lowering, which effectively performs a copy of the entire module's representation.

Then, it seems like this might make Naga's WGSL front end a lot more useful for progamming-in-the-large research: a linker system could ask Naga to parse modules, leaving external identifiers unresolved, and then patch up the Modules with definitions at link time, according to whatever semantics it liked. Type checking could be performed at validation time, after identifiers had been resolved, as it is now.

We already have some ideas about how to move constant evaluation later, so it wouldn't need to understand these unresolved variants.

Generally, our initial assumption in Naga's architecture has been that the best Module is one tailored for the backends' interests: anything that a backend isn't concerned with should be "boiled away" in the front ends, and never appear in a Module.

But we're seeing various places where this may be too restrictive:

• Abstract types should never be seen by a backend, but incorporating them into ScalarKind was a huge help, and it hasn't caused backends much trouble.

• Part of the motivation for introducing compaction was to allow validation to continue to be strict, but in [naga] Add phony as naga-ir statement #6308 (review) I'm wondering whether compaction throws away so much that we can't do the validation required by WGSL. (Not sure about this.)

• It may make Module less useful for tools, as explained above.

• It may be forcing more complexity on the WGSL front end, as explained above.