[Mesa-stable] [Mesa-dev] [PATCH 04/15] glsl: Add preprocessor error condition for #else directive
Carl Worth
cworth at cworth.org
Wed Jun 11 20:00:31 PDT 2014
Carl Worth <cworth at cworth.org> writes:
> I'll poke around at the existing code to see why the garbage after #else
> is caught with #if 0, but not with #if 1.
The difference is fairly straightforward, but it's going to be tricky to
fix.
Currently, the parser has a production for HASH_ELSE and NEWLINE tokens
that looks roughly like this:
HASH_ELSE { change_skip_state(); } NEWLINE
That is, the production matches an "#else" followed immediately by a
newline, (without anything in between), but the mid-rule action causes
the lexer state to change. This means that in the following case:
#if 0
#else garbage
#endif
between the "#if 0" and the "#else", the lexer will be skipping any
non-preprocessor directives. But it will start lexing identifiers again
just in time to catch "garbage" which leads to the desired parse error.
But in the following case:
#if 1
#else garbage
#endif
Here, at the #else we are now switching from not skipping to skipping,
and since the switch happens immediately after the "#else", then the
text of "garbage" gets skipped (along with everything after it and
before the #endif).
We could move the skip switching to after the NEWLINE, (avoiding the
tricky mid-rule action), like so:
HASH_ELSE NEWLINE { change_skip_state(); }
But that would just switch the behavior, (so that the "#if 1" case would
flag the error, but the "#if 0" case would not).
I'm still mulling over a nice clean fix here. (Though I am used to the
fact that with the preprocessor, there's rarely a clean fix---always
more ugly state to communicate from the parser to the lexer.) If anyone
wants to experiment or offer an idea, I'll be happy for the help.
-Carl
--
carl.d.worth at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-stable/attachments/20140611/08cc44f7/attachment.sig>
More information about the mesa-stable
mailing list