summaryrefslogtreecommitdiffstats
path: root/src/glsl/glcpp/tests
Commit message (Collapse)AuthorAgeFilesLines
* glcpp: error on multiple #else/#elif directivesErik Faye-Lund2014-01-024-0/+28
| | | | | | | | | | | | | | | | | | | | | The preprocessor currently accepts multiple else/elif-groups per if-section. The GLSL-preprocessor is defined by the C++ specification, which defines the following parse-rule: if-section: if-group elif-groups(opt) else-group(opt) endif-line This clearly only allows a single else-group, that has to come after any elif-groups. So let's modify the code to follow the specification. Add test to prevent regressions. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Carl Worth <[email protected]> Cc: 10.0 <[email protected]>
* glcpp: Replace multi-line comment with a space (even as part of macro ↵Carl Worth2014-01-025-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | definition) The preprocessor has always replaced multi-line comments with a single space character, (as required by the specification), but as of commit bd55ba568b301d0f764cd1ca015e84e1ae932c8b the lexer also emitted a NEWLINE token for each newline within the comment, (in order to preserve line numbers). The emitting of NEWLINE tokens within the comment broke the rule of "replace a multi-line comment with a single space" as could be exposed by code like the following: #define FOO a/* */b FOO Prior to commit bd55ba568b301d0f764cd1ca015e84e1ae932c8b, this code defined the macro FOO as "a b" as desired. Since that commit, this code instead defines FOO as "a" and leaves a stray "b" in the output. In this commit, we fix this by not emitting the NEWLINE tokens while lexing the comment, but instead merely counting them in the commented_newlines variable. Then, when the lexer next encounters a non-commented newline it switches to a NEWLINE_CATCHUP state to emit as many NEWLINE tokens as necessary (so that subsequent parsing stages still generate correct line numbers). Of course, it would have been more clear if we could have written a loop to emit all the newlines, but flex conventions prevent that, (we must use "return" for each token we emit). It similarly would have been clear to have a new rule restricted to the <NEWLINE_CATCHUP> state with an action much like the body of this if condition. The problem with that is that this rule must not consume any characters. It might be possible to write a rule that matches a single lookahead of any character, but then we would also need an additional rule to ensure for the <EOF> case where there are no additional characters available for the lookahead to match. Given those considerations, and given that the SKIP-state manipulation already involves a code block at the top of the lexer function, before any rules, it seems best to me to go with the implementation here which adds a similar pre-rule code block for the NEWLINE_CATCHUP. Finally, this commit also changes the expected output of a few, existing glcpp tests. The change here is that the space character resulting from the multi-line comment is now emitted before the newlines corresponding to that comment. (Previously, the newlines were emitted first, and the space character afterward.) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72686 Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glcpp: Add test case for recently fixed loop-control underflow bug.Carl Worth2013-06-032-0/+25
| | | | | | | To trigger the bug, it suffices to have a line-continuation followed by a newline and then a non-line-continuation backslash. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/build: Build glcpp via the glsl MakefileMatt Turner2013-01-221-2/+2
| | | | | | Removing the subdirectory recursion provides a small speed up. Tested-by: Andreas Boll <[email protected]>
* glcpp: Add tests for line continuationCarl Worth2013-01-114-0/+46
| | | | | | | | | First we test that line continuations are honored within a comment, (as recently changed in glcpp), then we test that line continuations can be disabled via an option within the context. This is tested via the new support for a test-specific command-line option passed to glcpp. Reviewed-by: Kenneth Graunke <[email protected]>
* glcpp: Allow test-specific arguments for standalone glcpp testsCarl Worth2013-01-111-2/+9
| | | | | | | | This will allow the test exercising disabled line continuations to arrange for the --disable-line-continuations argument to be passed to the standalone glcpp. Reviewed-by: Kenneth Graunke <[email protected]>
* glcpp: Add test involving token pasting of INTEGER tokens.Carl Worth2012-11-292-0/+15
| | | | | | | | | | | | | | | This test file is very similar to test 113-line-and-file-macros but uses token pasting for cleaner quiz answers (without spaces between the digits). This test passes thanks to the recent addition of support for pasting INTEGER tokens, (but would have failed without that). (Note that this test is distinct from test 059-token-pasting-integer which pastes integers parsed from the source. Those are parsed to INTEGER_STRING tokens and are already pasted correctly as verified by that test. The only way to generate the INTEGER tokens which currently fail to paste is with an internal define such as __LINE__ that results in an integer.) Reviewed-by: Matt Turner <[email protected]>
* glcpp: Extend the invalid-paste testCarl Worth2012-11-292-0/+20
| | | | | | | | The current code lets a few invalid pastes through, such as an string pasted onto the end of an integer. Extend the invalid-paste test to catch some of these. Reviewed-by: Matt Turner <[email protected]>
* glcpp: Add support for __LINE__ and __FILE__ macrosCarl Worth2012-11-292-0/+15
| | | | | | | | | | | | | These tokens are easy to expand by just looking at the current, tracked location values, (and no need to look anything up in the hash table). Add a test which verifies __LINE__ with several values, (and verifies __FILE__ for the single value of 0). Our testing framework isn't sophisticated enough here to have a test with multiple file inputs. This commit fixes part of es3conform's preprocess16_frag test. Reviewed-by: Matt Turner <[email protected]>
* glcpp: Support #elif(expression) with no intervening space.Matt Turner2012-11-286-0/+95
| | | | | | | | | | | | And add test cases to ensure that this works - 110 verifies that glcpp rejects #elif<digits> which glcpp previously accepted. - 111 verifies that glcpp accepts #if followed immediately by (, +, -, !, or ~. - 112 does the same as 111 but for #elif. See 17f9beb6 for #if change. Reviewed-by: Carl Worth <[email protected]>
* glcpp: Reject #version and #line not followed by whitespaceMatt Turner2012-11-284-0/+6
| | | | | Fixes part of es3conform's preprocess16_frag test. Reviewed-by: Carl Worth <[email protected]>
* glcpp: wire up glcpp-test to make checkMatt Turner2012-11-091-4/+12
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* glcpp/tests: Add tests for multiline #elifMatt Turner2012-11-092-0/+15
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* glcpp/tests: Add test for multiline #ifMatt Turner2012-11-092-0/+13
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* glcpp/tests: Add test for multiline #lineMatt Turner2012-11-092-0/+11
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* glcpp/tests: Add test to check #line followed by codeMatt Turner2012-11-092-0/+5
| | | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51802 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51506 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41152 Reviewed-by: Kenneth Graunke <[email protected]>
* glcpp: don't push #line directives into next lineFabian Bieler2012-11-091-1/+1
| | | | | | | | | | | | | | By moving the HASH_LINE rule out of control_line: and into line:, we avoid adding control_line's additional \n (as seen in the first hunk). mattst88: Carl and I determined independently of Fabian that the 091 test needed to be modified identically to this, and our patch to fix the test was more complicated. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51506 Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Carl Worth <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glcpp: Reject garbage after #else and #endif tokensMatt Turner2012-11-094-0/+11
| | | | | | | | | | | | | | | | | | | | | | Previously we were accepting garbage after #else and #endif tokens when the previous preprocessor conditional evaluated to false (eg, #if 0). When the preprocessor hits a false conditional, it switches the lexer into the SKIP state, in which it ignores non-control tokens. The parser pops the SKIP state off the stack when it reaches the associated #elif, #else, or #endif. Unfortunately, that meant that it only left the SKIP state after the lexing the entire line containing the #token and thus would accept garbage after the #token. To fix this we use a mid-rule, which is executed immediately after the #token is parsed. NOTE: This is a candidate for the stable branch Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56442 Fixes: preprocess17_frag.test from oglconform Reviewed-by: Carl Worth <[email protected]> (glcpp-parse.y) Acked-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: glcpp: Extend testing of #line directivesCarl Worth2012-06-262-0/+12
| | | | | | | | The most recent commit adds support for comments and macro expansion on #line directives. Add testing to verify the new features. Signed-off-by: Carl Worth <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: glcpp: Move handling of #line directives from lexer to parser.Carl Worth2012-06-261-4/+4
| | | | | | | | | | | | | | | | | | | The GLSL specification requires that #line directives be interpreted after macro expansion. Our existing implementation of #line macros in the lexer prevents conformance on this point. Moving the handling of #line from the lexer to the parser gives us the macro expansion we need. An additional benefit is that the preprocessor also now supports comments on the same line as #line directives. Finally, the preprocessor now emits the (fully-macro-expanded) #line directives into the output. This allows the full GLSL compiler to also see and interpret these directives so it can also generate correct line numbers in error messages. Signed-off-by: Carl Worth <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: glcpp: Allow "#if undefined-macro' to evaluate to false.Carl Worth2012-06-264-3/+17
| | | | | | | | | | | | | | | | | A strict reading of the GLSL specification would have this be an error, but we've received reports from users who expect the preprocessor to interepret undefined macros as 0. This is the standard behavior of the rpeprocessor for C, and according to these user reports is also the behavior of other OpenGL implementations. So here's one of those cases where we can make our users happier by ignoring the specification. And it's hard to imagine users who really, really want to see an error for this case. The two affected tests cases are updated to reflect the new behavior. Signed-off-by: Carl Worth <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Add glcpp tests for a macro used twiceCarl Worth2012-02-022-0/+33
| | | | | | | | | | | | | This test cases exposes a bug as described in this bug report: "ralloc.c:78: get_header: Assertion `info->canary == 0x5A1106' failed." when using a macro in GLSL https://bugs.freedesktop.org/show_bug.cgi?id=45082 Clearly, some memory is getting (incorrectly) freed on the first macro invocation, leading to problems with the second macro invocation. Reviewed-by: Kenneth Graunke <[email protected]>
* glcpp: Add new test showing bug where a trailing ':' prevents macro expansionCarl Worth2012-02-022-0/+15
| | | | | | | | | | | This demonstrates a bug that was recently triggered in piglit. Here is the original bug report (containing a test case almost identical to this one): https://bugs.freedesktop.org/show_bug.cgi?id=44764 Reviewed-by: Kenneth Graunke <[email protected]>
* Revert "src/glsl/glcpp: wire up glcpp-test to make check"Matt Turner2012-01-311-5/+1
| | | | This reverts commit 2bb9f9e1fda61fceb9284cbb4619d7e60e39f190.
* src/glsl/glcpp: wire up glcpp-test to make checkMatt Turner2012-01-301-1/+5
| | | | | | Reviewed-by: Eric Anholt <[email protected]> Tested-by: Eric Anholt <[email protected]> Signed-off-by: Matt Turner <[email protected]>
* glcpp-test: don't return failure if valgrind tests aren't runMatt Turner2012-01-301-1/+1
| | | | | | | | | | | | Success was (tests-passed AND valgrind-tests-passed) but this meant that if the valgrind tests weren't run it would be considered a failure. The logic is now (tests-passed AND (!valgrind OR valgrind-tests-passed)) which lets us return success if the valgrind tests aren't run. Reviewed-by: Eric Anholt <[email protected]> Tested-by: Eric Anholt <[email protected]> Signed-off-by: Matt Turner <[email protected]>
* glcpp: Add a test for #elif with an undefined macro.Carl Worth2011-09-302-0/+8
| | | | | | | | | | | | | | | | | | As written, this test correctly raises an error for #elif being used with an undefined macro (and not as an argument to "defined"). If the preceding #if were '#if 1' then this diagnositc would correctly be hidden. That allows code such as the following to not raise an error: #ifndef MAYBE_UNDEFINED #elif MAYBE_UNDEFINED < 5 ... #endif So this test case is working as expected already. We add it here just to improve test coverage. Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Carl Worth <[email protected]>
* glcpp: Raise error if defining any macro containing two consecutive underscoresCarl Worth2011-09-302-1/+5
| | | | | | | | | | | | | | | | | | The specification reserves any macro name containing two consecutive underscores, (anywhere within the name). Previously, we only raised this error for macro names that started with two underscores. Fix the implementation to check for two underscores anywhere, and also update the corresponding 086-reserved-macro-names test. This also fixes the following two piglit tests: spec/glsl-1.30/preprocessor/reserved/double-underscore-02.frag spec/glsl-1.30/preprocessor/reserved/double-underscore-03.frag Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Carl Worth <[email protected]>
* glcpp: Test a non-function-like macro using the token paste operatorCarl Worth2011-09-302-0/+7
| | | | | | | | Apparently we never implemented this, (but we've got a GLSL 1.30 test in piglit that is exercising this case). Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Carl Worth <[email protected]>
* glcpp: Add a test for a macro that implements token pasting twice.Carl Worth2011-09-302-0/+7
| | | | | | | This is something that piglit is exercising that currently fails. Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Carl Worth <[email protected]>
* Add expected file for 095-recursive-define test case.Carl Worth2011-04-141-0/+4
| | | | | | | | | | It's clear enough that the current segmentation fault isn't what we want. And it's also very easy to know what we do want here, (just check with any functional C preprocessor such as "gcc -E"). Add the desired output as an expected file so that the test suite gives useful output, (showing the omitted output and the segfault), rather than just reporting "No such file" for the expected file.
* glcpp: Add --valgrind option to the glcpp-test utilityCarl Worth2011-04-141-16/+46
| | | | | | | | | | | The common case for this test suite is to quickly test that everything returns the correct results. In this case, the second run of the test suite under valgrind was just annoying, (and the user would often interrupt it). Now, do what is wanted in the common case by default (just run the test suite), and require a run with "glcpp-test --valgrind" in order to test with valgrind.
* Add an expected file for 084-unbalanced-parenthesesCarl Worth2011-04-141-0/+2
| | | | | | | | | | | | The expected file here captures the current behavior of glcpp (which is to generate an obscure "syntax error, unexpected $end" diagnostic for this case). It would certainly be better for glcpp to generate a nicer diagnostic, (such as "missing closing parenthesis in function-like macro definition" or so), but the current behavior is at least correct, and expected. So we can make the test suite more useful by marking the current behavior as expected.
* Add an expected file for 094-divide-by-zero-short-circuitCarl Worth2011-04-142-0/+26
| | | | | | | | | | | The expected file here captures the current behavior of glcpp (which is to generate a division-by-zero error) for this case. It's easy to argue that it should be short-circuiting the evaluation and not generating the diagnostic (which happens to be what gcc does). But it doesn't seem like we should force this behavior on our pre-processor, (and, as always, the GLSL specification of the pre-processor is too vague on this point).
* Add an expected file for 093-divide-by-zeroCarl Worth2011-04-141-0/+4
| | | | | | This test is behaving just fine already---it's generating an informative diagnostic, ("error: division by 0 in preprocessor directive"), so adding this in the expected file makes things pass.
* glcpp/tests: Update 063-comments.c.expected to match output.Kenneth Graunke2011-03-031-0/+7
| | | | | | | The expected result has been out of sync with what glcpp produces for some time; glcpp's actual result seems to be correct and is very close to GCC's cpp. Updating this will make it easier to catch regressions in upcoming commits.
* Revert "glcpp: Demote "macro redefined" from an error to a warning"Carl Worth2011-01-291-6/+6
| | | | | | | | This reverts commit d3df641f0aba99b0b65ecd4d9b06798bca090a29. 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).
* glcpp: Demote "macro redefined" from an error to a warningCarl Worth2011-01-281-6/+6
| | | | | | | | | | 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.
* glcpp: Add test for recursive #define.Vinson Lee2011-01-041-0/+3
|
* glcpp: Add division by zero test cases.Vinson Lee2011-01-042-0/+4
|
* glcpp: Add negative tests for redefintions with valueless macros.Vinson Lee2010-12-272-0/+15
|
* glcpp: Fix test suite to avoid flagging failed tests as valgrind errors.Carl Worth2010-08-231-4/+5
| | | | | | | | | | 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.
* glcpp: Add new test for #line directive.Carl Worth2010-08-232-0/+21
| | | | | | | | | | | | 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 #
* glcpp: Add test for the #error directive.Carl Worth2010-08-232-0/+4
| | | | | | | 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).
* glcpp: Add two new tests for testing redefined macros.Carl Worth2010-08-174-0/+58
| | | | | | 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).
* glcpp: Fix 064-version.c expected result to track recent change.Carl Worth2010-08-171-1/+0
| | | | | | 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.
* glcpp: Add testcase for #if handling bug that breaks Savage2.Eric Anholt2010-08-172-0/+11
|
* glcpp: Fix "unterminated if" diagnostic.Carl Worth2010-08-111-0/+5
| | | | | | | | | | | 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.
* glcpp: Add an explicit diagnostic for #if with no expression.Carl Worth2010-08-111-1/+4
| | | | | | | 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.
* glcpp: Reword diagnostic for #elif with no expressionCarl Worth2010-08-111-1/+0
| | | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-21 13:35:19 +0000