Closed nolanderc closed 10 months ago
Perhaps you have already thought of that, but the glslang reference compiler has a ton of test glsl code. Look at this beauty of a file, for example.
It's mixed with a lot of irrelevant tests, unfortunately, so it probably needs some manual filtering, but that'd be my first place to look for lots of glsl.
Also thanks a bunch for the fixes on #6, #7, and #8, you rock!
Also is there a way to run the parser standalone on a file and not as an lsp request?
It would be easier to batch run this on a bunch of files if you could glsl_analyzer --dev-parse-file="test.glsl"
or similar. Sorry, I know neither zig nor lsp, but I wouldn't mind gathering some glsl code and running the parser tests on it.
@automaticp Not currently. However it should be quite easy to add. I’ll take a look later
Added a --parse-file
and --print-ast
flag in v1.1.0
Thank you, seems to work well. I've got some hits already, no crashes, but the parser seems to be unable to parse some well-formed (according to glslang) code and spits out invalid
nodes.
I'll open an issue for the forthcoming reports on parser defects/crashes and will be posting problematic samples there as I find them. Tell me if you'd like an issue-per-bug instead.
You can keep them in a single issue since its probably fastest to just fix them all in bulk. If there's anything more complex we can split it out into its own issue later.
I should probably enable the diagnostics in the editor to make it easier to explore these issues interactively as well.
I'll have a look at what might be the cause of the issues tomorrow :slightly_smiling_face:
There have been a few bad parser bugs recently, which could have been caught if we had more/larger test cases which exercised more parts of the code.