Carl Worth <cwo...@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.wo...@intel.com
pgpf98d1NxLwn.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
