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.jus...@intel.com>
02/23 glsl/glcpp: Add support for comments between #define and macro identifier
Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>
03/23 glsl/glcpp: Remove some un-needed calls to NEWLINE_CATCHUP
* Reference 6005e9cb in comment?
Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>
04/23 glsl/glcpp: Add testing for EOF sans newline (and fix for
<DEFINE>, <COMMENT>)
Reviewed-by: Jordan Justen <jordan.l.jus...@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.jus...@intel.com>
06/23 glsl/glcpp: Abstract a bit of common code for returning string tokens
Reviewed-by: Jordan Justen <jordan.l.jus...@intel.com>
On Thu, Jun 26, 2014 at 3:19 PM, Carl Worth <cwo...@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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
