You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've done some initial work porting WGSL's grammar to Bison so we can determine whether its ambiguous or not. Here's the work-in-progress, as of 3c633ea:
The grammar isn't LALR(1) today because of func_call_statement. For example, in foo(...) = 5; vs foo(...);, the differentiator (= vs ;) is many tokens after the point where we have to pick a path. I think this is fixable by rejiggering the grammar because foo(...) = 5; is illegal in WGSL (for now) anyway.
Bison doesn't support the * and + and ? operators that are in the spec's grammar, so I had to replace them with additional helper rules. (Which is fine.)
I've done some initial work porting WGSL's grammar to Bison so we can determine whether its ambiguous or not. Here's the work-in-progress, as of 3c633ea:
wgsl.y.zip
A few observations:
type_decl argument_expression_listcasts. See the discussion about this in Rename 'as' to bitcast; remove 'cast' #1047 and https://docs.google.com/document/d/1LN-L9UEtLPFKfou7jrpiSLH42xGp5ybvKaBHFTc4VKg/edit#heading=h.hp3f2zbslxr9func_call_statement. For example, infoo(...) = 5;vsfoo(...);, the differentiator (=vs;) is many tokens after the point where we have to pick a path. I think this is fixable by rejiggering the grammar becausefoo(...) = 5;is illegal in WGSL (for now) anyway.*and+and?operators that are in the spec's grammar, so I had to replace them with additional helper rules. (Which is fine.)In https://docs.google.com/document/d/1LN-L9UEtLPFKfou7jrpiSLH42xGp5ybvKaBHFTc4VKg/edit#heading=h.hp3f2zbslxr9 we decided to try to rejigger the grammar to be LALR(1) and see if it's possible without too much trouble, so we'll investigate doing that.
I don't think there was a resolution about what to do about casts. I expect we'll discuss this in the coming meeting.