|
dc0fa46a
|
2017-02-01T14:44:43
|
|
preprocessor: Check for line number overflow
Also remove dead code in Tokenizer.l
BUG=chromium:668842
Change-Id: Ice18313a64f0bb2242299993bfaa882a6578ad54
Reviewed-on: https://chromium-review.googlesource.com/435042
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
|
|
f81ce4a3
|
2017-04-24T10:49:17
|
|
Refactoring: replace NULL by nullptr for pointers (3rd CL).
This CL mainly handles passing/returning NULL to/from a function.
BUG=angleproject:2001
Change-Id: I34802f792e710e3d7ff697cbe4701dc1bf5ab009
Reviewed-on: https://chromium-review.googlesource.com/485060
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
47c27e82
|
2017-01-17T15:29:35
|
|
Manage preprocessor Macro objects with shared pointers
This ensures that pointers to Macros that are removed from the macro
set stay valid. Pointers to undef'd macros may need to be referred to
if reenabling the macros has been deferred.
BUG=chromium:681324
TEST=angle_unittests
Change-Id: Ibbbabbcbd6b0a84254cda717ae63712e6d404ebd
Reviewed-on: https://chromium-review.googlesource.com/427948
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
f1cf5e63
|
2016-11-22T17:36:49
|
|
Prevent stack overflow in macro expansion
Add a configurable limit for how many nested MacroExpander objects can
be created in the preprocessor, so that stack overflow can be
prevented in case of malicious shaders. By default the limit is set to
1000. In unit tests the limit is set lower to make the test run
faster.
Includes refactoring of most of the preprocessor tests so that they
use utility functions provided by the test class instead of repeating
the same code for initializing the preprocessor.
BUG=angleproject:1600
TEST=angle_unittests
Change-Id: I23b5140d9f2dc52df96111650db63150f7238494
Reviewed-on: https://chromium-review.googlesource.com/413986
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
|
|
|
78b0c91d
|
2016-11-21T14:23:06
|
|
Fix infinite recursion in macro expansion
BUG=angleproject:1600
TEST=angle_unittests
Change-Id: I72bf81ec060f36255a0f13b132a4fd69b89672ff
Reviewed-on: https://chromium-review.googlesource.com/412744
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
449a8030
|
2016-10-26T08:05:54
|
|
MacroExpander: bump expansionCount before peeking for "("
BUG=658555
Change-Id: I578b8aff37a116fd7b2b387388311a27bb8a2809
Reviewed-on: https://chromium-review.googlesource.com/403848
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
|
|
|
7f9a55f7
|
2016-10-03T14:32:08
|
|
Fix integer math overflows in the preprocessor
Evaluating integer expressions in the ESSL preprocessor may result in
overflowing the signed integer range. Implement wrapping overflow for
preprocessor expressions in a way that doesn't hit any undefined
behavior. In the ESSL spec, preprocessor expressions are defined to
have mostly the same semantics as in C++. Since C++ doesn't define
what happens on signed integer overflow, we choose to make most of the
operators wrap on overflow for backward compatibility and consistency
with the rest of the ESSL spec.
We reuse the existing wrapping overflow helpers that are
used for constant folding. To be able to do this, the type used in the
preprocessor expression parser is changed from 64-bit to 32-bit.
Shifting negative numbers is implemented as a logical shift. This
cannot be disallowed since dEQP requires shaders shifting negative
numbers to pass compilation.
Undefined bitwise shifts where the offset is greater than 31 will now
result in a compile-time error.
A couple of test cases are now covered by the preprocessor tests
rather than full compilation tests. This isolates the tests better and
they run faster.
BUG=chromium:652223
TEST=angle_unittests
Change-Id: I84be40d404c10ecd0846c5d477e626a94a2a8587
Reviewed-on: https://chromium-review.googlesource.com/392146
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
d2f195b5
|
2016-09-19T15:53:33
|
|
preprocessor: Fix use after free when #undef the macro being invoked
BUG=chromium:648031
BUG=angleproject:1522
Change-Id: I825cea9e736a2c99133408249cfcd525431d31de
Reviewed-on: https://chromium-review.googlesource.com/386853
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
461e3af8
|
2016-07-21T18:15:34
|
|
preprocessor: Fix negative shift with bad ids.
Fix this by producing an error on undefined or negative shifts.
BUG=629518
Change-Id: Idfca5ed3fc8e557f6178408f3426a5ef2ce7cf14
Reviewed-on: https://chromium-review.googlesource.com/362020
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
1b2f1629
|
2016-03-04T15:06:51
|
|
Forbid defined operator generated by macro expansion
After lengthy debate, the GLES working group recommended that this
should be an error in WebGL, though old specs were not updated. Make
ANGLE follow the WebGL spec and generate an error in this case.
This is a partial revert of the patch which added support for defined
operator generated by macro expansion. The preprocessor unit tests
added by the reverted commit are kept, but their expectations are
changed.
This breaks some dEQP tests that are not in line with the WebGL spec.
BUG=angleproject:1335
TEST=angle_unittests, WebGL conformance tests
Change-Id: I7d8a1d42c61367197f2aed4ca4de9297cc48acfc
Reviewed-on: https://chromium-review.googlesource.com/352471
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
2f6ddf31
|
2015-09-22T16:10:07
|
|
Allow double underscore in macro names
Double underscore is allowed according to GLSL ES 3.10, and based on
Khronos discussions the intent is that this should also apply to older
specs. The dEQP tests also check this, and WebGL tests that check the
opposite were recently removed. The error is changed into a warning.
BUG=angleproject:989
TEST=angle_unittests
dEQP-GLES3.functional.shaders.preprocessor.* (2 tests start passing)
dEQP-GLES2.functional.shaders.preprocessor.* (2 tests start passing)
Change-Id: I582c01b4adc8fc416354351e02b776f2cc602408
Reviewed-on: https://chromium-review.googlesource.com/300965
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tryjob-Request: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
247374cb
|
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>
|
|
|
3187a38e
|
2015-09-09T12:00:12
|
|
Make preprocessor ExpressionParser only lex what it can parse
This cleans up ExpressionParser so that the lexer only consumes one extra
token in case the parser finishes. The parser will also finish with
YYACCEPT once it has parsed a complete expression. This will make the
preprocessor to generate a more informative unexpected token error
instead of a syntax error if there are extra tokens after #if.
This will also enable reusing ExpressionParser for parsing expressions in
line directives. The format for a line directive that specifies both line
and file numbers is as follows:
#if line-expression file_expression
ExpressionParser will need to be run twice for each line: first to parse
line-expression and then to parse file-expression. For that reason, it is
essential that ExpressionParser for line-expression stops before
consuming more than one token of file-expression.
BUG=angleproject:989
TEST=angle_unittests, dEQP-GLES3.functional.shaders.preprocessor.*
Change-Id: I0bb92f733c18891eeddbc61e7c5bebdf1003559a
Reviewed-on: https://chromium-review.googlesource.com/300962
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tryjob-Request: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
261f5379
|
2015-09-18T10:34:31
|
|
Support parsing defined operator generated by macro expansion
dEQP tests enforce that the defined operator should be parsed even when
it is generated as a result of macro expansion, even though this is
undefined according to the C++ preprocessor spec.
Implement support for this by putting the parsing for the defined
operator inside MacroExpander. The operator gets processed right after
it is generated by macro expansion. Parsing the defined operator is
toggled with a boolean according to the context where MacroExpander
is used.
BUG=angleproject:989
TEST=angle_unittests,
dEQP-GLES3.functional.shaders.preprocessor.* - 2 tests start passing:
dEQP-GLES3.functional.shaders.preprocessor.conditional_inclusion.basic_2*
Change-Id: I780e63bd4558253657d898685d62339017564a06
Reviewed-on: https://chromium-review.googlesource.com/300970
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
e6432c85
|
2015-09-08T14:21:38
|
|
Fix preprocessor macro replacement list location
According to the dEQP tests, a macro replacement list generated by a
function-like macro invocation should get its location from the closing
parenthesis of the invocation. The tests check this by using __LINE__ in
a macro with a multi-line invocation. It's not quite clear from the spec
that the enforced behavior is expected as opposed to the replacement
list getting its location from the macro name, but a minor correction to
the preprocessor makes the dEQP tests pass.
Newlines in the preprocessor unit tests are generated according to the
source locations in the token list produced by the preprocessor, so the
expectations of a few tests also need to be updated.
BUG=angleproject:989
TEST=dEQP-GLES3.functional.shaders.preprocessor.predefined_macros.*
(2 start passing with this change),
angle_unittests
Change-Id: I4cc9da09bd0985310a05ebf6def680916a46308a
Reviewed-on: https://chromium-review.googlesource.com/297990
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
|
|
|
809ec546
|
2015-08-26T14:30:57
|
|
Don't evaluate short-circuited preprocessor expressions
Resubmit with clang build issue fixed. The result of a short-circuited
operation is now either 0 or 1.
ESSL 3.00 spec section 3.4 mentions that the second operand in a logical
&& or || preprocessor operation is evaluated only if the first operand
doesn't short-circuit the expression. The non-evaluated part of a
preprocessor expression may also have undefined identifiers.
Make the expression parser follow the spec by ignoring errors that are
generated inside short-circuited expressions. This includes undefined
identifiers and divide by zero.
BUG=angleproject:347
TEST=dEQP-GLES3.functional.shaders.preprocessor.undefined_identifiers.*
angle_unittests
Change-Id: I4163f96ec46d40ac859ffb39d91b89490041e44d
Reviewed-on: https://chromium-review.googlesource.com/297252
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
9a1b49f7
|
2015-09-08T14:32:26
|
|
Revert "Don't evaluate short-circuited preprocessor expressions"
Build break on Clang:
FAILED: /b/build/goma/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/third_party/angle/src/compiler/preprocessor/preprocessor.ExpressionParser.o.d -DV8_DEPRECATION_WARNINGS -DCLD_VERSION=2 -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORE=0 -DCHROMIUM_BUILD -DCR_CLANG_REVISION=245965-1 -DUSE_LIBJPEG_TURBO=1 -DENABLE_ONE_CLICK_SIGNIN -DENABLE_PRE_SYNC_BACKUP -DENABLE_WEBRTC=1 -DENABLE_MEDIA_ROUTER=1 -DUSE_PROPRIETARY_CODECS -DENABLE_PEPPER_CDMS -DENABLE_CONFIGURATION_POLICY -DENABLE_NOTIFICATIONS -DENABLE_HIDPI=1 -DSYSTEM_NATIVELY_SIGNALS_MEMORY_PRESSURE -DDONT_EMBED_BUILD_METADATA -DDCHECK_ALWAYS_ON=1 -DFIELDTRIAL_TESTING_ENABLED -DENABLE_TASK_MANAGER=1 -DENABLE_EXTENSIONS=1 -DENABLE_PDF=1 -DENABLE_PLUGIN_INSTALLATION=1 -DENABLE_PLUGINS=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 -DENABLE_AUTOFILL_DIALOG=1 -DENABLE_BACKGROUND=1 -DENABLE_GOOGLE_NOW=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 -DUSE_BROWSER_SPELLCHECKER=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1 -DENABLE_SUPERVISED_USERS=1 -DENABLE_SERVICE_DISCOVERY=1 -DENABLE_WIFI_BOOTSTRAPPING=1 -DV8_USE_EXTERNAL_STARTUP_DATA -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DSAFE_BROWSING_SERVICE -DUSE_LIBPCI=1 -DUSE_OPENSSL=1 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -Igen -isysroot /Applications/Xcode5.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -O2 -gdwarf-2 -fvisibility=hidden -Werror -Wnewline-eof -mmacosx-version-min=10.6 -arch x86_64 -Wendif-labels -Wno-unused-parameter -Wno-missing-field-initializers -Wno-selector-type-mismatch -Wpartial-availability -Wheader-hygiene -Wno-char-subscripts -Wno-unneeded-internal-declaration -Wno-covered-switch-default -Wstring-conversion -Wno-c++11-narrowing -Wno-deprecated-register -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-unused-function -Wno-unused-variable -std=c++11 -fno-rtti -fno-exceptions -fvisibility-inlines-hidden -fno-threadsafe-statics -Xclang -load -Xclang /b/build/slave/GPU_Mac_Builder/build/src/third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang check-templates -fcolor-diagnostics -fno-strict-aliasing -c ../../third_party/angle/src/compiler/preprocessor/ExpressionParser.cpp -o obj/third_party/angle/src/compiler/preprocessor/preprocessor.ExpressionParser.o
../../third_party/angle/src/compiler/preprocessor/ExpressionParser.cpp:1372:35: error: use of logical '||' with constant operand [-Werror,-Wconstant-logical-operand]
(yyval) = (yyvsp[-3]) || 0;
^ ~
../../third_party/angle/src/compiler/preprocessor/ExpressionParser.cpp:1372:35: note: use '|' for a bitwise operation
(yyval) = (yyvsp[-3]) || 0;
^~
|
../../third_party/angle/src/compiler/preprocessor/ExpressionParser.cpp:1406:35: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand]
(yyval) = (yyvsp[-3]) && 0;
^ ~
../../third_party/angle/src/compiler/preprocessor/ExpressionParser.cpp:1406:35: note: use '&' for a bitwise operation
(yyval) = (yyvsp[-3]) && 0;
^~
&
../../third_party/angle/src/compiler/preprocessor/ExpressionParser.cpp:1406:35: note: remove constant to silence this warning
(yyval) = (yyvsp[-3]) && 0;
~^~~~
BUG=angleproject:347
This reverts commit 6ffe613518482b966b913013c51221ce06ca7c33.
Change-Id: I6d81666cca573f320bfb1164a6c794b6f75f7463
Reviewed-on: https://chromium-review.googlesource.com/298020
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
|
|
|
6ffe6135
|
2015-08-26T14:30:57
|
|
Don't evaluate short-circuited preprocessor expressions
ESSL 3.00 spec section 3.4 mentions that the second operand in a logical
&& or || preprocessor operation is evaluated only if the first operand
doesn't short-circuit the expression. The non-evaluated part of a
preprocessor expression may also have undefined identifiers.
Make the expression parser follow the spec by ignoring errors that are
generated inside short-circuited expressions. This includes undefined
identifiers and divide by zero.
BUG=angleproject:347
TEST=dEQP-GLES3.functional.shaders.preprocessor.undefined_identifiers.*
angle_unittests
Change-Id: Ieed02a71298af838f784a5d1197d4f4a9ba0e3c8
Reviewed-on: https://chromium-review.googlesource.com/295033
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
2728f992
|
2015-08-31T16:24:10
|
|
Make unittest #includes start from src
This is will help avoid adding many include directories for the GN
build.
BUG=angleproject:929
Change-Id: If8f7e98526df3560b8e410ec86271a2da0c6889d
Reviewed-on: https://chromium-review.googlesource.com/296480
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Corentin Wallez <cwallez@chromium.org>
|
|
|
26e355b8
|
2015-08-14T14:16:19
|
|
Add full support for line continuation in the preprocessor
Re-landing earlier change with constant signedness fixed (was causing
build issues on Linux).
Line continuation in ESSL 3.00 needs to be processed before tokenization,
since tokens can span the line continuation. On the other hand, ANGLE's
tokenizer keeps track of line numbers, and whenever a line continuation
appears the line number still needs to be incremented by one, just like
on a regular newline.
That's why line continuation is now implemented as follows: when the
shader strings are concatenated in Input, they are also checked for line
continuation. Whenever line continuation is encountered, the string
is cut before that point. When the tokenizer asks for more input, the
string starting from the character after line continuation is passed
to it, and the line number is incremented from Input. This way the
tokenizer can parse tokens that span multiple lines - it never sees the
line continuation - but still keeps track of the line number correctly.
Relevant spec is in ESSL 3.00 section 3.2 "Source strings".
Support for line continuation also applies to ESSL 1.00. ESSL 3.00
spec section 1.5 says that line continuation support is mandated when
an ESSL 1.00 shader is used with the OpenGL ES 3.0 API, and is optional
when ESSL 1.00 is used with the OpenGL ES 2.0 API.
TEST=dEQP-GLES3.functional.shaders.preprocessor.line_continuation.*
(all pass),
angle_unittests
BUG=angleproject:1125
Change-Id: Ic086aacac53cd75bf93c0fda782416501d2f842b
Reviewed-on: https://chromium-review.googlesource.com/294200
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
3b040eb8
|
2015-08-17T16:51:33
|
|
Revert "Add full support for line continuation in the preprocessor"
Warning in the Linux/Mac builders:
In file included from ../../third_party/angle/src/tests/preprocessor_tests/input_test.cpp:7:
In file included from ../../third_party/angle/src/tests/preprocessor_tests/PreprocessorTest.h:7:
../../testing/gtest/include/gtest/gtest.h:1392:16: error: comparison of integers of different signs: 'const int' and 'const unsigned long' [-Werror,-Wsign-compare]
if (expected == actual) {
~~~~~~~~ ^ ~~~~~~
../../testing/gtest/include/gtest/gtest.h:1422:12: note: in instantiation of function template specialization 'testing::internal::CmpHelperEQ<int, unsigned long>' requested here
return CmpHelperEQ(expected_expression, actual_expression, expected,
^
../../third_party/angle/src/tests/preprocessor_tests/input_test.cpp:171:5: note: in instantiation of function template specialization 'testing::internal::EqHelper<false>::Compare<int, unsigned long>' requested here
EXPECT_EQ(3, input.read(buf, maxSize, &lineNo));
^
BUG=angleproject:1125
This reverts commit c1157d1963170c7411eb6c32e2b2fbce02c5a170.
Change-Id: Ic6fa286d190b006cccc5154d86e21ecc03175763
Reviewed-on: https://chromium-review.googlesource.com/294080
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
|
|
|
c1157d19
|
2015-08-14T14:16:19
|
|
Add full support for line continuation in the preprocessor
Line continuation in ESSL 3.00 needs to be processed before tokenization,
since tokens can span the line continuation. On the other hand, ANGLE's
tokenizer keeps track of line numbers, and whenever a line continuation
appears the line number still needs to be incremented by one, just like
on a regular newline.
That's why line continuation is now implemented as follows: when the
shader strings are concatenated in Input, they are also checked for line
continuation. Whenever line continuation is encountered, the string
is cut before that point. When the tokenizer asks for more input, the
string starting from the character after line continuation is passed
to it, and the line number is incremented from Input. This way the
tokenizer can parse tokens that span multiple lines - it never sees the
line continuation - but still keeps track of the line number correctly.
Relevant spec is in ESSL 3.00 section 3.2 "Source strings".
Support for line continuation also applies to ESSL 1.00. ESSL 3.00
spec section 1.5 says that line continuation support is mandated when
an ESSL 1.00 shader is used with the OpenGL ES 3.0 API, and is optional
when ESSL 1.00 is used with the OpenGL ES 2.0 API.
TEST=dEQP-GLES3.functional.shaders.preprocessor.line_continuation.*
(all pass),
angle_unittests
BUG=angleproject:1125
Change-Id: I1c1de49602e7cd755d6072c3c0aa5524cd0313b4
Reviewed-on: https://chromium-review.googlesource.com/293721
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
391befef
|
2015-08-12T16:30:38
|
|
Revert "Add pragma errors for malformed pragmas."
Since this commit was made, dEQP tests were fixed to check that
unrecognized pragma tokens only generate warnings, not errors.
This applies to both ESSL1.00 and ESSL3.00, which specify this
behavior in section 3.4 Preprocessor.
BUG=angleproject:989
TEST=dEQP-GLES2.functional.shaders.preprocessor.pragmas.*
This reverts commit d3c29f57aaeb451b149bbb9fd17b3f1f99101c52.
Change-Id: Ie4e0ec061fa3164d6f3872ac0016a063056ed110
Reviewed-on: https://chromium-review.googlesource.com/293181
Tested-by: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
1747603e
|
2015-07-29T09:54:40
|
|
Remove compiler_tests.gypi and preprocessor_tests.gypi.
These files were a relic of a previous structure, we can safely
remove them now that chrome uses angle_unittests.gypi.
BUG=None
TEST=compiles standalone and with chromium
Change-Id: If9a09122f664b740099b4270f5acc5627fc5ac35
Reviewed-on: https://chromium-review.googlesource.com/289343
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
b3a6a8f3
|
2015-06-23T16:10:14
|
|
Error when encountering non-preprocessor tokens before #extension in ESSL3.
BUG=angleproject:1047
Change-Id: I4a548270f651e35b2c8d1ab5d0f46185230c5f74
Reviewed-on: https://chromium-review.googlesource.com/281216
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Geoff Lang <geofflang@chromium.org>
|
|
|
4c8cae60
|
2015-05-01T16:46:16
|
|
Revert "Don't mark all macros with double underscores as reserved."
Fails a WebGL CTS test.
BUG=angleproject:989
This reverts commit 942e36254a1e3537371c39f3f23d1ce12f4c87e8.
Change-Id: I9f833366d5b69535ef74e358ac21efaccb1f1a3d
Reviewed-on: https://chromium-review.googlesource.com/268751
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Geoff Lang <geofflang@chromium.org>
|
|
|
942e3625
|
2015-04-30T11:00:01
|
|
Don't mark all macros with double underscores as reserved.
Only __FILE__, __LINE__, __VERSION__ and GL_ES are reserved but it is
still not recommended to use a name with double underscores because it may
be used by the "underlying software layers".
Updated the tests to reflect that it is OK to define macros with double
underscores but it is not valid to make assumptions about their values.
Fixes:
dEQP-GLES2.functional.shaders.preprocessor.basic.identifier_with_double_underscore_vertex
dEQP-GLES2.functional.shaders.preprocessor.basic.identifier_with_double_underscore_fragment
BUG=angleproject:898
Change-Id: I77054d04c9935eedcdbb7304dc0c3b60b53994f9
Reviewed-on: https://chromium-review.googlesource.com/268434
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Geoff Lang <geofflang@chromium.org>
|
|
|
d3c29f57
|
2015-04-28T11:23:02
|
|
Add pragma errors for malformed pragmas.
Instead of always warning on invalid pragmas, only warn when the pragma
type is not recognized and error when the syntax is invalid.
Fixes:
dEQP-GLES2.functional.shaders.preprocessor.pragmas.invalid_pragma_invalid_debug_vertex
dEQP-GLES2.functional.shaders.preprocessor.pragmas.invalid_pragma_invalid_debug_fragment
dEQP-GLES2.functional.shaders.preprocessor.pragmas.invalid_pragma_invalid_token_vertex
dEQP-GLES2.functional.shaders.preprocessor.pragmas.invalid_pragma_invalid_token_fragment
BUG=angleproject:989
Change-Id: Ibd584dc08a2436e163dfc52eeffdf2dac8a22cb8
Reviewed-on: https://chromium-review.googlesource.com/267639
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tested-by: Geoff Lang <geofflang@chromium.org>
|
|
|
08c9cd97
|
2015-04-22T11:39:20
|
|
Remove last uses of the enumerate_files script.
BUG=angleproject:981
Change-Id: Ib91d4b515e129241814706351b69a74e8295a250
Reviewed-on: https://chromium-review.googlesource.com/266874
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Geoff Lang <geofflang@chromium.org>
|
|
|
559a2e8c
|
2015-03-16T17:25:51
|
|
Move the ANGLE tests project to src/
*re-re-land with fix for Chrome's angle tests*
BUG=angleproject:945
Change-Id: I3c64e2edc776c299791440f65f22450855eb6dfa
Reviewed-on: https://chromium-review.googlesource.com/260448
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
96e3f556
|
2015-03-16T21:24:20
|
|
Revert "Move the ANGLE tests project to src/"
Still causing build issues on Chrome.
This reverts commit 64a3b2a92fe3bbd28972638e6759fae0b98d81b9.
Change-Id: I8d40fe3dfd0a877343357153a02b8ef66d571c64
Reviewed-on: https://chromium-review.googlesource.com/260425
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
|
|
|
64a3b2a9
|
2015-03-16T11:00:20
|
|
Move the ANGLE tests project to src/
*re-land with fix for Chromium build*
BUG=angleproject:945
Change-Id: I82bff1760e681987fb26e479734aa62fb845898a
Reviewed-on: https://chromium-review.googlesource.com/260362
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
5491fe66
|
2015-03-16T17:56:18
|
|
Revert "Move the ANGLE tests project to src/"
Causing build break in Chromium.
This reverts commit 71c2d85c4af2f6cb213d4f3e15f0ae16b63790f3.
Change-Id: Iedf001c1f4c60a759f69009610fbce978d193d17
Reviewed-on: https://chromium-review.googlesource.com/260370
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
|
|
|
71c2d85c
|
2015-03-16T10:47:04
|
|
Move the ANGLE tests project to src/
BUG=angleproject:945
Change-Id: I2eb44ac43f65b916ddd838d39e6aae62580d7fa0
Reviewed-on: https://chromium-review.googlesource.com/258903
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
|