Restrict grammar for @if

[stefnotch]

The wesl spec allows for attribute before assignments

@if(foo)
a = 3;

However, I am not sure how to implement that in the language server's parser. It requires arbitrary, complex lookahead. As in, the following is a problem to parse

@some_attr
(very + complex * (expression)) = 3;

When the parser sees the (, it has to make a choice. Does it parse it as an attribute @some_attr(very + complex * (expression)) or is the attribute finished (very + complex * (expression)) = 3;. With backtracking, that's doable. I really do not want backtracking in the language server parser, as it

• is significantly more complex to maintain
  • would mess with our error recovery capabilities
• introduces a source of slowdowns even for just WGSL (backtracking is a slowdown)
• still does not address the fundamental issue of this grammar being ambiguous

To elaborate on the last point, the WGSL grammar recently got extended to allow for function calls in the lhs side of an expression. The following is now syntactically valid WGSL.

foo() = 3;
(foo()) = 3;

If WGSL or WESL ever gets function pointers, then this would be valid WGSL. foo.bar is the function pointer and it's called with value

(foo.bar)(value) = 3;

Combining it with an ambiguous attribute, we get

@if
(foo.bar)(value) = 3;

Which is completely ambiguous. (foo.bar) might either be a part of the attribute or not. We can't have ambiguous grammars.

Now we could say that @if always requires ( after it and that parsing that attribute needs to happen during the parsing step, instead of afterwards.
However, that just punts the problem into the future for when we get around to user defined attributes. And it still leaves me with complications in wgsl-analyzer. Wgsl-analyzer's current attribute handling code is rather complex, further complicated by the fact that it supports both WGSL and WESL. I would like to have a single unified parser for "general" attributes and only assign a meaning to them in the syntax tree layer.

See also
webgpu-tools/wesl-rs#162
#171

Proposal

We should only allow @if before declarations. Everything else can be written as @if { whatever }
Concretely, we should only allow @if before

• const value declarations
• variable declarations
• directives
• struct declarations

[k2d222]

what about function declarations, parameters, struct members?

In wesl-rs I have a workaround where @if(expr) (expr) = expr; is considered invalid. Basically the production rule (lhs) = rhs is distinct from the ones without parentheses and doesn't accept if/elif/else attributes.

my concern with scoping @if() { stmt } is that it makes it impossible to assign different values to a let- or const-variable conditionally, as it must be initialized. my concern is that resorting to var-variables can behave slightly differently and/or be optimized differently, though it's just my guess and I don't have data to back this.

While translating bevy shaders I hit this case a lot.

example:

// x is i32 (inferred), and would be AbstractInt with a const.
@if(yes) let x = 1;
@else let x = 2;

// it becomes
var x: u32;
@if(yes) { x = 1; }
@else { x = 2; }

[BenjaminBrienen]

It's a shame attributes don't have an end token

[stefnotch]

Sorry, I wasn't clear enough with the proposal.

Of the existing rules https://github.com/webgpu-tools/wesl-spec/blob/main/ConditionalTranslation.md#update-to-the-wgsl-grammar , I am only proposing that we restrict the extensions to the WGSL attributes grammar. So everything would stay the same, except for the section "2. The grammar is extended to allow translate-time attributes before the following syntax nodes:"

[mighdoll]

So an attribute followed by a ( could either be:

• a parameter list for the attribute.
• a parameterless attribute followed by a statement that starts with a (.

FWIW, the wesl-js parser knows about @if/@elif and expects their parenthesized arguments. That's one way to avoid the ambiguity.

But that doesn't scale to generalized attribute parsing. If we want to have user-provided attributes that might not have parens, the parser can't easily know how to parse those..

I see a few ways to resolve the ambiguity:
1 - only allow WESL attributes on declarations. (proposal floated above)
2 - disallow WESL attributes on statements that start with a ( (wesl-rs currently)
3 - require that custom WESL attributes always have parens (plus probably parse @else w/o parens)

Of those options, I lean towards the wesl-rs approach. The ambiguity is a rare case, and easy for users to work around by adding curly brackets.

---

Related, there's the idea to allow an @if { ... } to float contents to the scope outside the brackets, like D. (currently experimental in wesl-js). e.g.,

@if(FOO) { const x = 1; } 
@else { const x = 2; } 
const y = x;

(I don't think that changes anything here, but mentioning for completeness.)

[stefnotch]

@mighdoll I just took a stab at trying to implement that behaviour in the language server. I don't know how to do it. The priority is not a simple "ordered choice" thing which is supported by most tools, but rather the conflict is hidden deeper inside the grammar rules. And there's already a different grammar rule that requires special casing with priorities, see wgsl-analyzer/wgsl-analyzer#896 .
(Edit: I figured it out. I still would need to investigate where it changes the error recovery though.)

Independent of implementation difficulties, I would argue for a grammar modification to be the sensible option. Formal language grammars as a whole have certain properties if and only if the entire grammar satisfies them. Special casing can really mess with tools, like lelwel, tree sitter or lezer. As a historical example, C and C++ are infamous for their difficult grammars and tooling has suffered for it. As a more recent example, as far as I understand it, current wesl-rs simply cannot implement that option.

[mighdoll]

So #1 is cleaner for a table driven grammar, but a bit awkward for users. It would prevent @if on assignments and fn calls, and return and discard, right? Or if we special case WESL @if in the parser, we could make it work for us, but a library that wants to implement say @trace placed on fn call statements would be more awkward.

#3 is also clean for grammar implementation, but user-awkward to always require parens on custom attributes. (And we'd special case @else presumably.)

#2 is cleaner for users but pushes more complexity onto the grammar to identify statements that start with (. I'll send a partial wgsl-analyzer patch that works w/o a custom predicate by duplicating one section of the grammar, like wesl-rs does. I'm sure it'd need work, but might be enough to evaluate the maintainability of that direction.

#4
Another idea is to defer the general attribute case for now. We'd do custom handling of @if/@elif/@else for now and defer figuring out how to lelwel parse custom attributes generally. If we eventually get to #2, we drop the special handling. If we end up with more limited custom attributes via #1 or #3, we can keep the @if/@elif/@else special handling.

[stefnotch]

Ah, I see what modification you would do. (Something small right here)

That has a catch: It also disallows the non-ambiguous case of attributes that have parens, like @foo() (*bar)();
Wait, I forgot that that case might become ambiguous in the future. So disallowing it is the correct choice.

In the lang server case, that is also leaky abstraction. It is only encoded in the rules of the parser and not in the syntax tree. So syntax tree rewrites (formatters, autocompletions and fixes for lints) would be prone to breaking the rule.

[stefnotch]

To elaborate on why I proposed the new ruleset where return and other statements are affected: I looked at the existing grammar and had to come up with a consistent language rule. Which here would be "attributes are allowed before declarations and before blocks".
Declarations are var, fn, struct, etc
Blocks are while ... {}, if ... { }, { }, etc

[stefnotch]

Am reading through the implementation right now, that is very interesting, thank you! Very nice use of a coding agent. I didn't realize that even a simple rule duplication would run into a LL(1) conflict.

I do have to say that it's a more involved implementation than I would have expected. Especially the duplication of the entire statement rule is making me worried. Yes, I could factor out the common parts, but at the cost of a fair amount of readability.

https://github.com/mighdoll/wgsl-analyzer/blob/e6c5966b16ec4a19f5508f37dc13d86106eef0b1/crates/parser/src/wesl.llw#L323

[stefnotch]

#4 seems doable to me, if we speedrun it and come to the conclusion that @if and @else are attributes that use keywords. So treating them specially until the end of time is fine. They come with their own weird set of rules.

• Keyword instead of a name, so users physically cannot define such attributes and the syntax tree layer won't return anything for a name
• @else must have a @if syntax tree node as a sibling
• @if does not allow for a general expression, instead it is a odd "translate time expression". One where normal type checking or const eval does not happen

In that world, @elif is a bit surprising though.

(Come to think of it, @else will be a pain to handle in a few places.)