summaryrefslogtreecommitdiffstats
path: root/src/glsl/glcpp/tests
Commit message (Collapse)AuthorAgeFilesLines
* glsl/glcpp: Drop extra, final newline from most outputCarl Worth2014-07-29127-127/+0
| | | | | | | | | | | | | | | | | | | | The glcpp parser is line-based, so it needs to see a NEWLINE token at the end of each line. This causes a trick for files that end without a final newline. Previously, the lexer for glcpp punted in this case by unconditionally returning a NEWLINE token at end-of-file, (causing most files to have an extra blank line at the end). Here, we refine this by lexing end-of-file as a NEWLINE token only if the immediately preceding token was not a NEWLINE token. The patch is a minor change that only looks huge for two reasons: 1. Almost all glcpp test result ".expected" files are updated to drop the extra newline. 2. All return statements from the lexer are adjusted to use a new RETURN_TOKEN macro that tracks the last-token-was-a-newline state. Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Add testing for EOF sans newline (and fix for <DEFINE>, <COMMENT>)Carl Worth2014-07-296-0/+8
| | | | | | | | | | | | | | | | The glcpp implementation has long had code to support a file that ends without a final newline. But we didn't have a "make check" test for this. Additionally, the <EOF> action was restricted only to the <INITIAL> state so it would fail to get invoked if the EOF was encountered in the <COMMENT> or the <DEFINE> case. Neither of these was a bug, per se, since EOF in either of these cases is an error anyway, (either "unterminated comment" or "missing macro name for #define"). But with the new explicit support for these cases, we not generate clean error messages in these cases, (rather than "unexpected $end" from before). Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Add support for comments between #define and macro identifierCarl Worth2014-07-292-0/+5
| | | | | | | | | | | | | | | The recent adddition of an error for "#define followed by a non-identifier" was a bit to aggressive since it used a regular expression in the lexer to flag any character that's not legal as the first character of an identifier. But we need to allow comments to appear here, (since we aren't removing comments in a preliminary pass). So we refine the error here to only flag characters that could not be an identifier, nor a comment, nor whitespace. We also augment the existing comment support to be active in the <DEFINE> state as well. Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Emit proper error for #define with a non-identifierCarl Worth2014-07-292-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, if the preprocessor encountered a #define with a non-identifier, such as: #define 123 456 The lexer had no explicit rules to match non-identifiers in the <DEFINE> start state. Because of this, flex's default rule was being invoked, (printing characters to stdout), and all text was being discarded by the compiler until the next identifier. As one can imagine, this led to all sorts of interesting and surprising results. Fix this by adding an explicit rule complementing the existing identifier-based rules that should catch all non-identifiers after #define and reliably give a well-formatted error message. A new test is added to "make check" to ensure this bug stays fixed. This commit also fixes the following Khronos GLES3 CTS test: define_non_identifier_vertex (The "fragment" variant was passing earlier only because the preprocessor was behaving so randomly and causing the compilation to fail. It's lucky, in fact, that the "vertex" version succesfully compiled so we could find and fix this bug.) Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Add testing for directives preceded by a spaceCarl Worth2014-07-292-0/+43
| | | | | This test simply has one of each directive, all of which are preceded by a single space character.
* glsl/glcpp: Fix to emit spaces following directivesCarl Worth2014-07-291-2/+2
| | | | | | | | | | | | | The glcpp lexer and parser use the space_tokens state bit to avoid emitting tokens for spaces while parsing a directive. Previously, this bit was only being set again by the first non-space token following a directive. This led to a bug where a space, (or a comment that should emit a space), immediately following a directive, (optionally searated by newlines), would be omitted from the output. Here we fix the bug by also setting the space_tokens bit whenever we lex a newline in the standard start conditions.
* glsl/glcpp: Don't choke on an empty pragmaCarl Worth2014-07-092-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | The lexer was insisting that there be at least one character after "#pragma" and before the end of the line. This caused an error for a line consisting only of "#pragma" which volates at least the following sentence from the GLSL ES Specification 3.00.4: The scope as well as the effect of the optimize and debug pragmas is implementation-dependent except that their use must not generate an error. [Page 12 (Page 28 of PDF)] and likely the following sentence from that specification and also in GLSLangSpec 4.30.6: If an implementation does not recognize the tokens following #pragma, then it will ignore that pragma. Add a "make check" test to ensure no future regressions. This change fixes at least part of the following Khronos GLES3 CTS test: preprocessor.pragmas.pragma_vertex Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/glcpp: Promote "extra token at end of directive" from warning to errorCarl Worth2014-07-092-0/+13
| | | | | | | | | | | | | | | | We've always warned about this case, but a recent confromance test expects this to be an error that causes compilation to fail. Make it so. Also add a "make check" test to ensure these errors are generated. This fixes the following Khronos GLES3 conformance tests: invalid_conditionals.tokens_after_ifdef_vertex invalid_conditionals.tokens_after_ifdef_fragment invalid_conditionals.tokens_after_ifndef_vertex invalid_conditionals.tokens_after_ifndef_fragment Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/glcpp: Once again report undefined macro name in error message.Carl Worth2014-07-091-2/+2
| | | | | | | | | | | While writing the previous commit message, I just felt bad documenting the shortcoming of the change, (that undefined macro names would not be reported in error messages). Fix this by preserving the first-encounterd undefined macro name and reporting that in any resulting error message. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/glcpp: Add short-circuiting for || and && in #if/#elif for OpenGL ES.Carl Worth2014-07-092-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GLSL ES Specification 3.00.4 says: #if, #ifdef, #ifndef, #else, #elif, and #endif are defined to operate as for C++ except for the following: ... • Undefined identifiers not consumed by the defined operator do not default to '0'. Use of such identifiers causes an error. [Page 11 (page 127 of the PDF file)] as well as: The semantics of applying operators in the preprocessor match those standard in the C++ preprocessor with the following exceptions: • The 2nd operand in a logical and ('&&') operation is evaluated if and only if the 1st operand evaluates to non-zero. • The 2nd operand in a logical or ('||') operation is evaluated if and only if the 1st operand evaluates to zero. If an operand is not evaluated, the presence of undefined identifiers in the operand will not cause an error. (Note that neither of these deviations from C++ preprocessor behavior apply to non-ES GLSL, at least as of specfication version 4.30.6). The first portion of this, (generating an error for an undefined macro in an (short-circuiting to squelch errors), was not implemented previously, but is implemented in this commit. A test is added for "make check" to ensure this behavior. Note: The change as implemented does make the error message a bit less precise, (it just states that an undefined macro was encountered, but not the name of the macro). This commit fixes the following Khronos GLES3 conformance test: undefined_identifiers.valid_undefined_identifier_1_vertex undefined_identifiers.valid_undefined_identifier_1_fragment undefined_identifiers.valid_undefined_identifier_2_vertex undefined_identifiers.valid_undefined_identifier_2_fragment Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/glcpp: Fix glcpp to properly lex entire "preprocessing numbers"Carl Worth2014-07-092-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The preprocessor defines a notions of a "preprocessing number" that starts with either a digit or a decimal point, and continues with zero or more of digits, decimal points, identifier characters, or the sign symbols, ('-' and '+'). Prior to this change, preprocessing numbers were lexed as some combination of OTHER and IDENTIFIER tokens. This had the problem of causing undesired macro expansion in some cases. We add tests to ensure that the undesired macro expansion does not happen in cases such as: #define e +1 #define xyz -2 int n = 1e; int p = 1xyz; In either case these macro definitions have no effect after this change, so that the numeric literals, (whether valid or not), will be passed on as-is from the preprocessor to the compiler proper. This fixes the following Khronos GLES3 CTS tests: preprocessor.basic.correct_phases_vertex preprocessor.basic.correct_phases_fragment v2. Thanks to Anuj Phogat for improving the original regular expression, (which accepted a '+' or '-', where these are only allowed after one of [eEpP]. I also expanded the test to exercise this. v3. Also fixed regular expression to require at least one digit at the beginning (after an optional period). Otherwise, a string such as ".xyz" was getting sucked up as a preprocessing number, (where obviously this should be a field access). Again, I expanded the test to exercise this. Reviewed-by: Anuj Phogat <[email protected]>
* glsl/glcpp: Fix glcpp to catch garbage after #if 1 ... #elseCarl Worth2014-07-094-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, a line such as: #else garbage would flag an error if it followed "#if 0", but not if it followed "#if 1". We fix this by setting a new bit of state (lexing_else) that allows the lexer to defer switching to the <SKIP> start state until after the NEWLINE following the #else directive. A new test case is added for: #if 1 #else garbage #endif which was untested before, (and did not generate the desired error). This fixes the following Khronos GLES3 CTS tests: tokens_after_else_vertex tokens_after_else_fragment Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* glsl/glcpp: Fixup glcpp tests for redefining a macro with whitespace changes.Carl Worth2014-07-093-1/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the test suite was expecting the compiler to allow a redefintion of a macro with whitespace added, but gcc is more strict and allows only for changes in the amounts of whitespace, (but insists that whitespace exist or not in exactly the same places). See: https://gcc.gnu.org/onlinedocs/cpp/Undefining-and-Redefining-Macros.html: These definitions are effectively the same: #define FOUR (2 + 2) #define FOUR (2 + 2) #define FOUR (2 /* two */ + 2) but these are not: #define FOUR (2 + 2) #define FOUR ( 2+2 ) #define FOUR (2 * 2) #define FOUR(score,and,seven,years,ago) (2 + 2) This change adjusts the existing "redefine-macro-legitimate" test to work with the more strict understanding, and adds a new "redefine-whitespace" test to verify that changes in the position of whitespace are flagged as errors. Reviewed-by: Anuj Phogat <[email protected]>
* glsl/glcpp: Add test to ensure compiler won't allow #undef for some builtinsCarl Worth2014-07-092-0/+10
| | | | | | | Currently verifying that an #undef of __FILE__, __LINE__, or __VERSION__ will generate an error. Reviewed-by: Anuj Phogat <[email protected]>
* glcpp: Do not remove spaces to preserve locations.Sir Anthony2014-03-083-4/+4
| | | | | | | | | After preprocessing by glcpp all adjacent spaces were replaced by single one and glsl parser received column-shifted shader source. It negatively affected ast location set up and produced wrong error messages for heavily-spaced shaders. Reviewed-by: Kenneth Graunke <[email protected]>
* glcpp: Only warn for macro names containing __Ian Romanick2014-02-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Section 3.3 (Preprocessor) of the GLSL 1.30 spec (and later) and the GLSL ES spec (all versions) say: "All macro names containing two consecutive underscores ( __ ) are reserved for future use as predefined macro names. All macro names prefixed with "GL_" ("GL" followed by a single underscore) are also reserved." The intention is that names containing __ are reserved for internal use by the implementation, and names prefixed with GL_ are reserved for use by Khronos. Since every extension adds a name prefixed with GL_ (i.e., the name of the extension), that should be an error. Names simply containing __ are dangerous to use, but should be allowed. In similar cases, the C++ preprocessor specification says, "no diagnostic is required." Per the Khronos bug mentioned below, a future version of the GLSL specification will clarify this. Signed-off-by: Ian Romanick <[email protected]> Cc: "9.2 10.0 10.1" <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Tested-by: Kenneth Graunke <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Tested-by: Darius Spitznagel <[email protected]> Cc: Tapani Pälli <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870 Bugzilla: Khronos #11702
* glcpp: Add "make check" test for comment-parsing bugCarl Worth2014-01-312-0/+5
| | | | | | | This is the innocent-looking but killer test case to verify the bug fixed in the preceding commit. Reviewed-by: Jordan Justen <[email protected]>
* 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 02:42:21 +0000