summaryrefslogtreecommitdiffstats
path: root/src/glsl/glcpp/tests/086-reserved-macro-names.c.expected
Commit message (Collapse)AuthorAgeFilesLines
* glsl: move to compiler/Emil Velikov2016-01-261-9/+0
| | | | | | Signed-off-by: Emil Velikov <[email protected]> Acked-by: Matt Turner <[email protected]> Acked-by: Jose Fonseca <[email protected]>
* glsl/glcpp: Fix off-by-one error in column in first-line error messagesCarl Worth2014-07-291-1/+1
| | | | | | | | | | | | | | For the first line we were initializing the column to 1, but for all subsequent lines we were initializing the column to 0. The column number is advanced for each token read before any error message is printed. So the 0 value is the correct initialization, (so that the first column is reported as column 1). With this extremely minor change, many of the .expected files are updated such that error messages for the first line now have the correct column number in them. Reviewed-by: Jordan Justen <[email protected]>
* glsl/glcpp: Drop extra, final newline from most outputCarl Worth2014-07-291-1/+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]>
* 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: Raise error if defining any macro containing two consecutive underscoresCarl Worth2011-09-301-1/+4
| | | | | | | | | | | | | | | | | | 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: Add several tests for diagnostics.Carl Worth2010-08-111-0/+7
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).