[Mesa-dev] glsl/glcpp: A bunch of pre-processor cleanups
cworth at cworth.org
Thu Jun 26 15:19:00 PDT 2014
Here's my latest series of patches to improve conformance of glcpp, (the glsl
preprocessor in mesa).
Most of these changes are fixes that only a test-suite author could love. Most
fix nit-picky tests that do things that no sance application would actually
do. They're all reasonable things to do, but few are likely to impact many
The entire series (as well as some earlier patches already reviewed) can be
found on the glcpp-fixup branch of my mesa tree:
Here's a run-down of what the changes are in this series:
Patch 01: Give an error for "#define 123" or similar non-identifier
Not a useful thing to do, of course, but an error we need.
Patch 02: Support comment here: "#define /* Ha! */ FOO"
Patches 03-12: Many cleanups/rewriting while working on the next patch
Patch 13: Support comment here: "# /* Tricky! */ define FOO"
Comments appearing in these places are not likely, but are clearly
valid according to the language specification. There was a bunch of
work necessary to make this fix easy, (and even with all the
preliminary work, the final patch was longer than I wanted).
I am happy that the lexer state at the end of this cleanup is much
simpler and easier to read than it was before.
Patch 14: Emit internal error for unrecognized character
This is to make un-subtle all classes of subtle bugs where the default
flex rule was simply printing unrecongized characters to stdout and
dropping them from the GLSL source.
This is not actually in glcpp but in the lexer for the main glsl
Patch 15: Emit error for bogus extra characters after #extension
This is an example of a fix for one of those subtle bugs from the flex
default-rule. This is a patch from Ken that was sent some time ago.
Patches 16-17: Trivial fixups (renaming of token identifiers and new comment)
Patch 18: Emit an error for duplicate macro parameter, eg "#define FOO(a, a)"
Patch 19: Emit error if "++" or "--" appear in preprocessor condition
Patches 20-21: Two new tests for bugs that I wrote (and fixed) while working
on some of the above.
Patch 22: Emit internal error for unrecognized character
This is just like patch 14, but for the lexer in glcpp itself.
Patch 23: Treat '\r' as equivalent to '\n'
The '\r' character was previously hitting the default lex, "print and
throw away" rule so was being entirely ignored. With patch 22, '\r'
would instead generate an internal error. Fix this by making '\r'
equivalent to '\n'.
I'd like to be even more spec-compliant for '\r', but I think this is
OK for now. I'd also like to add some more-exhaustive testing for
'\r', (such as running all of glcpp-test on the test cases with '\n'
changed to "\r\n").
More information about the mesa-dev