[Mesa-dev] [Mesa-stable] [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

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

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

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.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-dev/attachments/20140611/08cc44f7/attachment.sig>

More information about the mesa-dev mailing list