| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
We recently added several tests that intentionally trigger
preprocessor errors. During valgrind-based testing, our test script
was noticing the non-zero return value from the preprocessor and
incorrectly flagging the valgrind-based test as failing.
To fix this, we make valgrind return an error code that is otherwise
unused by the preprocessor.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 #
|
| |
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
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 6be3a8b70af4ba4fa4d037d54ecf6d5f055edbc9, 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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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 allows writing tests that verify diagnostics from the preprocessor.
|
| |
|
|
|
| |
The glcpp-test script was leaving around bogus *.valgrind-errors files if
a valgrind test was interrupted.
|
| |
|
|
|
|
| |
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 d4a04f315560704bf1103df0b93723e468725df7 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.
|
| | |
|
| |
|
|
| |
The original intention was to use #ifdef.
|
| |
|
|
| |
gcc and mesa master agree that this is OK.
|
| |
|
|
| |
I simply forgot to add this file when adding the test case originally.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, if the outer #ifdef/#ifndef evaluated to false, the inner
directive would not be parsed correctly, (the identifier as the subject
of the #ifdef/#ifndef would inadvertently be skipped along with the other
content correctly being skipped).
We fix this by setting the lexing_if state in each case here.
We also add a new test to the test suite to ensure that this case is tested.
|
| |
|
|
| |
And add a test case to ensure that this works.
|
| |
|
|
|
|
| |
As it turns out, 4 of our current tests are not valgrind clean,
(use after free errors or so), so this will be helpful for
investigating and fixing those.
|
| |
|
|
| |
And report PASS or FAIL for each test along the way as well.
|
| |
|
