[Mesa-dev] glsl/glcpp: A bunch of pre-processor cleanups

[Jordan Justen]

Made it ~25% through. :) I'll be busy for a bit, but I'll continue
looking at the rest later.

01/23 glsl/glcpp: Emit proper error for #define with a non-identifier
  Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>

02/23 glsl/glcpp: Add support for comments between #define and macro identifier
  Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>

03/23 glsl/glcpp: Remove some un-needed calls to NEWLINE_CATCHUP
  * Reference 6005e9cb in comment?
  Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>

04/23 glsl/glcpp: Add testing for EOF sans newline (and fix for
<DEFINE>, <COMMENT>)
  Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>

05/23 glsl/glcpp: Drop extra, final newline from most output
  * In the "<SKIP,INITIAL>\n {" section, you set
    "parser->last_token_was_newline = 1;"
    Doesn't "RETURN_TOKEN (NEWLINE);" do this as well?
  Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>

06/23 glsl/glcpp: Abstract a bit of common code for returning string tokens
  Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>

On Thu, Jun 26, 2014 at 3:19 PM, Carl Worth <cworth at cworth.org> wrote:
> 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
> real applications.
>
> The entire series (as well as some earlier patches already reviewed) can be
> found on the glcpp-fixup branch of my mesa tree:
>
>         git://people.freedesktop.org/~cworth/mesa
>
> 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
>         compiler.
>
> 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").
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev