|
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>
|
|
946903d2
|
2016-04-18T17:30:07
|
|
Remove usage of auto_ptr in MacroExpander
BUG=angleproject:1269
Change-Id: I1fafa102b065f6da1797e8790ec3ed498d9d8b45
Reviewed-on: https://chromium-review.googlesource.com/339379
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
|
|
|
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>
|
|
|
e5a1f271
|
2015-08-21T02:58:25
|
|
Use override in all the places where it is possible
This will avoid -Winconsistent-overrides in the future. Done using the
-Wsuggest-override warning of GCC 5.1
BUG=
Change-Id: I707a649dc368f5dd1e139fd144370abcac0b6263
Reviewed-on: https://chromium-review.googlesource.com/294920
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Corentin Wallez <cwallez@chromium.org>
|
|
0a73dd85
|
2014-11-19T16:18:08
|
|
Fix include guards.
BUG=angle:733
Change-Id: I08b2c11c4831f1161c178c1842b10e807185aced
Reviewed-on: https://chromium-review.googlesource.com/230831
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Geoff Lang <geofflang@chromium.org>
|
|
d526f989
|
2014-05-13T14:51:19
|
|
Fix code style violation in compiler/preprocessor
BUG=angle:650
TEST=no behavior change
Change-Id: Ib52f15f6471fc7897b66d11baee11216cf08158a
Reviewed-on: https://chromium-review.googlesource.com/199591
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Tested-by: Zhenyao Mo <zmo@chromium.org>
|
|
a16a55f7
|
2012-12-20T20:51:54
|
|
Add explicit std:: namespace to code from <cXYZ> includes.
Some platforms seem to implicitly include the <XYZ.h> headers
which also add some types and functions (like strlen, size_t,...)
into the global namespace.
On other platforms though, this can result in compile errors, which
is noticeable in WebKit on e.g. QNX. See also:
https://bugs.webkit.org/show_bug.cgi?id=95468
https://codereview.appspot.com/6843083/
Contributed by Milian Wolff, Klaralvdavens Datakonsult AB.
git-svn-id: https://angleproject.googlecode.com/svn/branches/dx11proto@1565 736b8ea6-26fd-11df-bfd4-992fa37f6226
|
|
|
b401a92b
|
2012-10-26T18:58:24
|
|
Move the new preprocessor out of the 'new' directory.
TRAC #21966
Signed-off-by: Daniel Koch
Author: Nicolas Capens
git-svn-id: https://angleproject.googlecode.com/svn/trunk@1326 736b8ea6-26fd-11df-bfd4-992fa37f6226
|