glcpp: Don't enter lexer's NEWLINE_CATCHUP start state for single-line comments
authorCarl Worth <cworth@cworth.org>
Wed, 29 Jan 2014 21:19:39 +0000 (13:19 -0800)
committerCarl Worth <cworth@cworth.org>
Fri, 31 Jan 2014 18:02:36 +0000 (10:02 -0800)
commit71978cf66fe52152f376fb896b1b4d2f1624777d
treed853ce0ee2d623d3bb056eb201d6a3a12920baac
parentdf21f31788f2dc610ac069b92e5ab652d7e78bcd
glcpp: Don't enter lexer's NEWLINE_CATCHUP start state for single-line comments

In commit 6005e9cb28 a new start state of NEWLINE_CATCHUP was added to the
lexer. This start state is used whenever the lexer is emitting a NEWLINE token
to emit additional NEWLINE tokens for any newline characters that were skipped
by an immediately preceding multi-line comment.

However, that commit erroneously entered the NEWLINE_CATCHUP state for
single-line comments. This is not desired since in the case of a single-line
comment, the lexer is not emitting any NEWLINE token. The result is that the
lexer will remain in the NEWLINE_CATCHUP state and proceed to fail to emit a
NEWLINE token for the subsequent newline character, (since the case to match \n expects only the INITIAL start state).

The fix is quite simple, remove the "BEGIN NEWLINE_CATCHUP" code from the
single-line comment case, (preserving it only in exactly the cases where the
lexer is actually emitting a NEWLINE token).

Many thanks to Petri Latvala for reporting this bug and for providing the
minimal test case to exercise it. The bug showed up only with a multi-line
comment which was followed immediately by a single-line comment (without any
intervening newline), such as:

/*
        */ // Kablam!

Since 6005e9cb28, and before this commit, that very innocent-looking
combination of comments would yield a parse failure in the compiler.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72686

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
src/glsl/glcpp/glcpp-lex.l