diff options
author | Carl Worth <[email protected]> | 2014-01-29 13:19:39 -0800 |
---|---|---|
committer | Carl Worth <[email protected]> | 2014-01-31 10:02:36 -0800 |
commit | 71978cf66fe52152f376fb896b1b4d2f1624777d (patch) | |
tree | d853ce0ee2d623d3bb056eb201d6a3a12920baac /src/mesa/program/prog_statevars.c | |
parent | df21f31788f2dc610ac069b92e5ab652d7e78bcd (diff) |
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 <[email protected]>
Diffstat (limited to 'src/mesa/program/prog_statevars.c')
0 files changed, 0 insertions, 0 deletions