This error message was missing so that the program would simply
segfault if the provided filename could not be opened for some reason.
While we're at it, we add explicit support for a filename of "-" to
indicate input from stdin.
The existing DECIMAL_INTEGER pattern is the correct thing to use when
looking for a C decimal integer, (that is, a digit-sequence not
starting with 0 which would instead be an octal integer).
But for #line, we really want to accept any digit sequence, (including
"0"), and always interpret it as a decimal constant. So we add a new
DIGITS pattern for this case.
This should fix the compilation failure noted in bug #28138https://bugs.freedesktop.org/show_bug.cgi?id=28138
(Though the generated file will not be updated until the next commit.)
Previously, the YY_USER_ACTION was overwriting the yylloc->source value
in every action, (after that value had been carefully set by the handling
of the #line directive). Instead, we want to initialize it once in
YY_USER_INIT and then not touch it at all in YY_USER_ACTION.
This test exposes two current bugs:
1. The source number is not being correctly emitted in error
messages (instead, it's always 0).
2. A directive of "#line 0" is resulting in the following
parse error:
preprocessor error: Invalid tokens after #
The README file had grown a little bit stale. We've been using newer
versions of both the GLSL and C99 specifications, so list those. Also,
several of the documented known limitations have since been fixed, so
remove those.
This directive is already implemented nicely, but wasn't previously tested.
It will be convenient to use this directive in further tests that rely
on error messages, (such as ensuring that #line correctly sets the line
number in the error message).
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.
The specification says that redefining a macro is an error, unless the
new definitions is identical to the old one, (identical replacement
lists but ignoring differing amounts of whitespace).
In commit 6be3a8b70a, the #version directive
was fixed to stop generating a spurious newline. Here we simply update
the expected result for the single test which includes a #version directive.
Matching the newline here meant having to do some redundant work here,
(incrementing line number, resetting column number, and returning a
NEWLINE token), that could otherwise simply be left to the existing rule
which matches a newline.
Worse, when the comment rule matches the newline as well, the parser
can lookahead and see a token for something that should actually be skipped.
For example, in a case like this:
#if 0 // comment here
fail
#else
win
#endif
Both fail and win appear in the output, (not that the condition is being
evaluated incorrectly---merely that one token after the comment's newline
was being lexed/parse regardless of the condition).
This commit fixes the above test case, (which is also remarkably similar
to 087-if-comments which now passes).
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.
Which are proving to be useful since some of these tests are not yet
acting as desired, (in particular, the unterminated if test is not
generating any diagnostic).
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).
We're already using the return-value of cmp to print either PASS or
FAIL and in the case of failure, we're subsequently running and
showing the output of diff. So any warnings/errors from cmp itself are
not actually needed, and can be quite confusing.
Commit d4a04f3155 caused this test case
to produce an additional blank line, which is otherwise harmless, but
does need to be reflected in the .expected file for the test to pass.
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.
