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
To be clear, C-style cast syntax isn't supported in GLSL, so glslang is correct in reporting a syntax error. The real problem is that the parse errors that glslang outputs are not very useful (this is a big down-side to their use of a parser generator).
In this case I assume Slang is in what I call "full rewriter" mode, where it doesn't even parse function bodies. This mode is what happens if Slang is being invoked with semantic off and there are no import declarations. We reproduce the input function body exactly and glslang gives a parse error.
I suspect that in the "rewriter with imports" mode (when we see at least one import, and actually do parse function bodies) this case would work by accident because the cross-compiler logic is set up to turn HLSL casts into GLSL constructor calls. This behavior is technically a bug, since it means we accept invalid GLSL, but I'm okay with us accepting a useful superset of GLSL.
The right long-term fix is for Slang to either always accept this syntax in GLSL, and validate it so that glslang never sees it, or never accept C-style casts in GLSL but report our own error message that is more clear ("GLSL does not support C-style cast syntax") to spare the user.
A useful goal for Slang would be that the user never sees a parse error from glslang.
Not a Slang issue.
imageStore(gOutput, (ivec2)crd, pixelated.bgra);
The error message I'm getting is
syntax error, unexpected RIGHT_PAREN, expecting LEFT_PAREN
The text was updated successfully, but these errors were encountered: