There was already a loop here to look for multiple token pastes, but
it was mistakenly incrementing the iterator counter after performing
one paste.
Instead, leave the loop iterator in place to coalesce as many tokens
as necessary into one.
This fixes the recently add 096-paste-twice test as well as the
following piglit test:
spec/glsl-1.30/preprocessor/concat/concat-03.frag
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Carl Worth <cworth@cworth.org>
The 095-recursive-define test case was triggering infinite recursion
with the following test case:
#define A(a, b) B(a, b)
#define C A(0, C)
C
Here's what was happening:
1. "C" was pushed onto the active list to expand the C node
2. While expanding the "0" argument, the active list would be
emptied by the code at the end of _glcpp_parser_expand_token_list
3. When expanding the "C" argument, the active list was now empty,
so lather, rinse, repeat.
We fix this by adjusting the final popping at the end of
_glcpp_parser_expand_token_list to never pop more nodes then this
particular invocation had pushed itself. This is as simple as saving
the original state of the active list, and then interrupting the
popping when we reach this same state.
With this fix, all of the glcpp-test tests now pass.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32835
Signed-off-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-and-tested-by: Kenneth Graunke <kenneth@whitecape.org>
These were all written as generic list functions, (accepting and returning
a list to act upon). But they were only ever used with parser->active as
the list. By simply accepting the parser itself, these functions can update
parser->active and now return nothing at all. This makes the code a bit
more compact.
And hopefully the code is no less readable since the functions are also
now renamed to have "_parser_active" in the name for better correlation
with nearby tests of the parser->active field.
For example, this now raises an error:
#define XXX 1 / 0
Fixes bug: https://bugs.freedesktop.org//show_bug.cgi?id=33507
Fixes Piglit test: spec/glsl-1.10/preprocessor/modulus-by-zero.vert
NOTE: This is a candidate for the 7.9 and 7.10 branches.
This reverts commit d3df641f0a.
The original commit had sat unpushed on my machine for months. By the
time I found it again, I had forgotten that we had decided not to use
this change after all, (the relevant test was removed long ago).
The GLSL specification is vague here, (just says "as is standard for
C++"), though the C specifications seem quite clear that this should
be an error.
However, an existing piglit test (CorrectPreprocess11.frag) expects
this to be a warning, not an error, so we change this, and document in
README the deviation from the specification.
When GCC encounters a division by zero in a preprocessor directive, it
generates an error. Since the GLSL spec says that the GLSL
preprocessor behaves like the C preprocessor, we should generate that
same error.
It's worth noting that I cannot find any text in the C99 spec that
says this should be an error. The only text that I can find is line 5
on page 82 (section 6.5.5 Multiplicative Opertors), which says,
"The result of the / operator is the quotient from the division of
the first operand by the second; the result of the % operator is
the remainder. In both operations, if the value of the second
operand is zero, the behavior is undefined."
Fixes 093-divide-by-zero.c test and bugzilla #32831.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
In _token_list_equal_ignoring_space(token_list_t*, token_list_t*), add
a guard that prevents dereferncing a null token list.
This fixes test src/glsl/glcpp/tests/092-redefine-macro-error-2.c and
Bugzilla #32695.
This is really supposed to be defined only if the driver supports highp
in the fragment shader - but all of our current ES2 implementations do.
So, just define it. In the future, we'll need to add a flag to
gl_context and only define the macro if the flag is set.
"Fixes" freedesktop.org bug #31673.
Carefully avoiding printing any error when the new definition matches
the existing definition.
This fixes the recently-added 088-redefine-macro-legitimate.c and
089-redefine-macro-error.c tests as well as glsparsertest/preprocess1
in piglit.
This was previously being appended to the output string *after* a copy
of the supposedly final string was made and handed to the caller. So
the diagnostic was never actually visible to the user.
We fix this by moving the check for an unterminated #if from
glcpp_parser_destroy to the calling function, preprocess.
This fixes the test case 083-unterminated-if.c.
This is more clear than the previously-generated diagnostic which was
something confusing like "enexpected newline".
This change makse test 080-if-witout-expression.c now pass.
Rather than telling the user what to fix, the standard convention is to
describe what the detected problem is. With this change, test
081-elif-without-expression now passes.
This adds a couple of test cases to expand our coverage of invalid #if and
being skipped, (either by being nested inside an #if/#elif that evaluates to
zero or by being after an #if/#elif that evaluates to non-zero).
Since we have a custom structure for YYLTYPE locations, we need to use
an %initial-action directive to avoid triggering use of uninitialized
memory when, for example, printing error messages.
We apparently don't yet have a test case that allowed valgrind to find
this bug for us, but valgrind found a similar problem in the other
parser, so we fix this one as well.
Calling exit() on a memory failure probably made sense for the
standalone preprocessor, but doesn't seem too appealing as part of
the GL library. Also, we don't use it in the main compiler.
The "%expect 0" construct will make bison emit an error if any future
changes to the grammar introduce shift/reduce conflicts, (without also
increasing the number after "%expect").
Since we have productions to turn "defined FOO" and "defined ( FOO )"
into a conditional_token we don't need to list DEFINED as an operator
as well. Doing so just introduces the shift/reduce ambiguity with no
benefit.
It's really hard to believe that this case has been broken, but apparently
no test previously exercised it. So this commit adds such a test and fixes
it by making a copy of the argument token-list before expanding it.
This fix causes the following glean tests to now pass:
glsl1-Preprocessor test 6 (#if 0, #define macro)
glsl1-Preprocessor test 7 (multi-line #define)
Consider this test case:
#define EMPTY
int foo = 1+EMPTY+4;
The expression should compile as the sequence of tokens 1, PLUS,
UNARY_POSITIVE, 4. But glcpp has been failing for this case since it
results in the string "1++4" which a compiler correctly sees as a
syntax error, (1, POST_INCREMENT, 4).
We fix this by changing any macro with an empty definition to result
in a single SPACE token rather than nothing. This then gives "1+ +4"
which compiles correctly.
This commit does touch up the two existing test cases which already
have empty macros, (to add the space to the expected result).
It also adds a new test case to exercise the above scenario.
Currently only GL_ARB_draw_buffers and GL_ARB_texture_rectangle are
defined because those extensions are always enabled. This make
tex_rect-03.frag pass.
