|
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>
|