Skip to content

A
angle
Switch branch/tag
  1. 09 Sep, 2015 2 commits
    • Fix preprocessor macro replacement list location · e6432c85
      Olli Etuaho authored 
      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/297990Tested-by: 's avatarOlli Etuaho <oetuaho@nvidia.com>
Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
Reviewed-by: 's avatarZhenyao Mo <zmo@chromium.org>
    • Don't split the file into two chunks in shader_translator · 0304d2fe
      Olli Etuaho authored 
      Splitting the file into two strings in shader_translator complicated
testing line/file numbering related functionality with it, since each
chunk passed to ShCompile has its own file number and line numbering.
These are exposed to the preprocessor in __FILE__ and __LINE__ predefined
macros.

Just supply the file to ShCompile in a single string. Also, since the
original motivation for splitting the string seems to have been to
exercise ShCompile with multiple strings, add a new unit test that
ensures that ShCompile handles multiple strings as expected.

BUG=angleproject:989
TEST=angle_unittests

Change-Id: I31d24925ec85ca3411e537df25a985f09737403e
Reviewed-on: https://chromium-review.googlesource.com/297251Tested-by: 's avatarOlli Etuaho <oetuaho@nvidia.com>
Reviewed-by: 's avatarZhenyao Mo <zmo@chromium.org>
  3. 08 Sep, 2015 11 commits
  5. 07 Sep, 2015 1 commit
    • Don't evaluate short-circuited preprocessor expressions · 6ffe6135
      Olli Etuaho authored 
      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/295033Reviewed-by: 's avatarZhenyao Mo <zmo@chromium.org>
Tested-by: 's avatarOlli Etuaho <oetuaho@nvidia.com>
  7. 04 Sep, 2015 13 commits
  9. 03 Sep, 2015 12 commits
  11. 02 Sep, 2015 1 commit