The NEWLINE_CATCHUP code is only intended to be invoked after we lex an actual
newline character ('\n'). The two extra calls here were apparently added
accidentally because the pattern happened to contain a (negated) '\n'.
I don't think either case could have caused any actual bug. (In the first
case, the pattern matched right up to the next newline, so the NEWLINE_CATCHUP
code was just about to be called. In the second case, I don't think it's
possible to actually enter the <SKIP> start condition after commented newlines
without any intervening newline.)
But, if nothing else, the code is cleaner without these extra calls.
---
src/glsl/glcpp/glcpp-lex.l | 4 ----
1 file changed, 4 deletions(-)
diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
index 91d4c13..0975006 100644
--- a/src/glsl/glcpp/glcpp-lex.l
+++ b/src/glsl/glcpp/glcpp-lex.l
@@ -181,8 +181,6 @@ HEXADECIMAL_INTEGER 0[xX][0-9a-fA-F]+[uU]?
/* glcpp doesn't handle #extension, #version, or #pragma directives.
* Simply pass them through to the main compiler's lexer/parser. */
{HASH}(extension|pragma)[^\n]* {
- if (parser->commented_newlines)
- BEGIN NEWLINE_CATCHUP;
yylval->str = ralloc_strdup (yyextra, yytext);
yylineno++;
yycolumn = 0;
@@ -230,8 +228,6 @@ HEXADECIMAL_INTEGER 0[xX][0-9a-fA-F]+[uU]?
}
<SKIP>[^\n] {
- if (parser->commented_newlines)
- BEGIN NEWLINE_CATCHUP;
}
{HASH}error.* {
--
2.0.0
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
