-
Show log
Commit
-
Hash : 247374cb
Author :
Date : 2015-09-09T15:07:24
Allow limited form of expressions in #line directives Reuse ExpressionParser that's also used for parsing preprocessor conditionals to parse line and file numbers in #line directives. According to recent Khronos discussions, the intent of the spec is that expressions in #line directives should be interpreted similarly to expressions in conditional directives, so reusing ExpressionParser is a natural way to implement this. This enables simple math operators operating on integers. There are a few unclear corner cases, but this approach is enough to support practical use cases and pass the dEQP tests. Valid line directives have one of the following forms: #line line-expression #line line-expression file-expression ExpressionParser is first run to parse the line-expression. In ambiguous cases the ExpressionParser consumes as much of the line as possible to form line-expression. Then, if end-of-line hasn't been reached, file-expression is parsed by running ExpressionParser again. As an example of an ambiguous case: #line 1 + 2 This could alternatively be interpreted to mean line-expression "1" and file-expression "+ 2" where + is the unary + operator, but ANGLE now interprets it to mean line-expression "1 + 2". Because of these ambiguous cases, a bison grammar that would parse multiple expressions on the same line couldn't be easily constructed, so this solution where ExpressionParser is run twice was chosen instead. The problematic corner cases are: - ExpressionParser uses 64-bit integers internally for evaluating the expression's value. It's possible to interpret the ESSL3 spec so that 32-bit integer wraparound behavior would be required also for #line directive expressions. - It's unclear whether the defined operator can be used in #line expressions. In this patch it is disabled. Hoping for further clarification from Khronos. - It's unclear how short-circuiting should affect the parsing of undefined identifiers in #line expressions. Now it's consistent with #if expressions (undefined identifiers are OK if they're short-circuited). dEQP expectations are updated for preprocessor tests, including ones not affected specifically by this change. BUG=angleproject:989 TEST=angle_unittests, dEQP-GLES3.functional.shaders.preprocessor.* (4 start passing), dEQP-GLES2.functional.shaders.preprocessor.* (4 start passing) Change-Id: I55c5bf75857da5de855cc600d3603ee19399f328 Reviewed-on: https://chromium-review.googlesource.com/300964 Reviewed-by: Jamie Madill <jmadill@chromium.org> Tryjob-Request: Olli Etuaho <oetuaho@nvidia.com> Tested-by: Olli Etuaho <oetuaho@nvidia.com>
-
Files
- 64bit-tokenizer-safety.patch
- DiagnosticsBase.cpp
- DiagnosticsBase.h
- DirectiveHandlerBase.cpp
- DirectiveHandlerBase.h
- DirectiveParser.cpp
- DirectiveParser.h
- ExpressionParser.cpp
- ExpressionParser.h
- ExpressionParser.y
- Input.cpp
- Input.h
- Lexer.cpp
- Lexer.h
- Macro.cpp
- Macro.h
- MacroExpander.cpp
- MacroExpander.h
- Preprocessor.cpp
- Preprocessor.h
- SourceLocation.h
- Token.cpp
- Token.h
- Tokenizer.cpp
- Tokenizer.h
- Tokenizer.l
- generate_parser.sh
- numeric_lex.h
- pp_utils.h
