summaryrefslogtreecommitdiffstats
path: root/src/glsl/glcpp
Commit message (Collapse)AuthorAgeFilesLines
...
* glsl/glcpp: Correctly parse directives with intervening commentsCarl Worth2014-07-2916-110/+242
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's legal (though highly bizarre) for a pre-processor directive to look like this: # /* why? */ define FOO bar This behavior comes about since the specification defines separate logical phases in a precise order, and comment-removal occurs in a phase before the identification of directives. Our implementation does not use an actual separate phase for comment removal, so some extra care is necessary to correctly parse this. What we want is for '#' to introduce a directive iff it is the first token on a line, (ignoring whitespace and comments). Previously, we had a lexical rule that worked only for whitespace (not comments) with the following regular expression to find a directive-introducing '#' at the beginning of a line: HASH ^{HSPACE}*#{HSPACE}* In this commit, we switch to instead use a simple literal match of '#' to return a HASH_TOKEN token and add a new <HASH> start condition for whenever the HASH_TOKEN is the first non-space token of a line. This requires the addition of the new bit of state: first_non_space_token_this_line. This approach has a couple of implications on the glcpp parser: 1. The parser now sees two separate tokens, (such as HASH_TOKEN and HASH_DEFINE) where it previously saw one token (HASH_DEFINE) for the sequence "#define". This is a straightforward change throughout the grammar. 2. The parser may now see a SPACE token before the HASH_TOKEN token of a directive. Previously the lexical regular expression for {HASH} would eat up the space and there would be no SPACE token. This second implication is a bit of a nuisance for the parser. It causes a SPACE token to appear in a production of the grammar with the following two definitions of a control_line: control_line SPACE control_line This is really ugly, since normally a space would simply be a token separator, so it wouldn't appear in the tokens of a production. This leads to a further problem with interleaved spaces and comments: /* ... */ /* ... */ #define /* ..*/ For this, we must not return several consecutive SPACE tokens, or else we would need an arbitrary number of new productions: SPACE SPACE control_line SPACE SPACE SPACE control_line ad nauseam To avoid this problem, in this commit we also change the lexer to emit only a single SPACE token for any series of consecutive spaces, (whether from actual whitespace or comments). For this compression, we add a new bit of parser state: last_token_was_space. And we also update the expected results of all necessary test cases for the new compression of space tokens. Fortunately, the compression of spaces should not lead to any semantic changes in terms of what the eventual GLSL compiler sees. So there's a lot happening in this commit, (particularly for such a tiny feature). But fortunately, the lexer itself is looking cleaner than ever. The only ugly bit is all the state updating, but it is at least isolated to a single shared function. Of course, a new "make check" test is added for the new feature, (directives with comments and whitespace interleaved in many combinations). And this commit fixes the following Khronos GLES3 CTS tests: function_definition_with_comments_vertex function_definition_with_comments_fragment Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Rename HASH token to HASH_TOKENCarl Worth2014-07-292-5/+8
| | | | | | | | | | | This is in preparation for the planned addition of a new <HASH> start condition to the lexer. Both start conditions and token types are, of course, in the same default C namespace, so a start condition and a token type with the same name will collide. (And unfortunately, they are both apparently implemented as equivalent numeric types so the collision is undetected at compile time and simply leads to unpredictable behavior at run time.) Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Don't use start-condition stack when switching to/from <DEFINE>Carl Worth2014-07-291-3/+3
| | | | | | | | | | | | | | | | | | | | | This commit does not cause any behavioral change for any valid program. Prior to entering the <DEFINE> start condition, the only valid start condition is <INITIAL>, so whether pushing/popping <DEFINE> onto the stack or explicit returning to <INITIAL> is equivalent. The reason for this change is that we are planning to soon add a start condition for <HASH> with the following semantics: <HASH>: We just saw a directive-introducing '#' <DEFINE>: We just saw "#define" starting a directive With these two start conditions in place, the only correct behavior is to leave <DEFINE> by returning to <INITIAL>. But the old push/pop code would have returned to the <HASH> start condition which would then cause an error when the next directive-introducing '#' would be encountered. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Add a -d/--debug option to the standalone glcpp programCarl Worth2014-07-292-1/+7
| | | | | | | | | The verbose debug output from the parser is quite useful when debugging, and having this available as a command-line option is much more convenient than manually forcing this into the code when needed, (which is what I had been doing for too long previously). Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Fix off-by-one error in column in first-line error messagesCarl Worth2014-07-2917-19/+19
| | | | | | | | | | | | | | 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 <jordan.l.justen@intel.com>
* glsl/glcpp: Minor tweak to wording of error messageCarl Worth2014-07-293-3/+3
| | | | | | It makes more sense to print the directive name with the preceding '#'. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Stop using a lexer start condition (<SKIP>) for token skipping.Carl Worth2014-07-293-63/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here, "skipping" refers to the lexer not emitting any tokens for portions of the file within an #if condition (or similar) that evaluates to false. Previously, the lexer had a special <SKIP> start condition used to control this skipping. This start condition was not handled like a normal start condition. Instead, there was a particularly ugly block of code set to be included at the top of the generated lexing loop that would change from <INITIAL> to <SKIP> or from <SKIP> to <INITIAL> depending on various pieces of parser state, (such as parser->skip_state and parser->lexing_directive). Not only was that an ugly approach, but the <SKIP> start condition was complicating several glcpp bug fixes I attempted recently that want to use start conditions for other purposes, (such as a new <HASH> start condition). The recently added RETURN_TOKEN macro gives us a convenient way to implement skipping without using a lexer start condition. Now, at the top of the generated lexer, we examine all the necessary parser state and set a new parser->skipping bit. Then, in RETURN_TOKEN, we examine parser->skipping to determine whether to actually emit the token or not. Besides this, there are only a couple of other places where we need to examine the skipping bit (other than when returning a token): * To avoid emitting an error for #error if skipped. * To avoid entering the <DEFINE> start condition for a #define that is skipped. With all of this in place in the present commit, there are hopefully no behavioral changes with this patch, ("make check" still passes all of the glcpp tests at least). Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Abstract a bit of common code for returning string tokensCarl Worth2014-07-291-22/+18
| | | | | | | Now that we have a common macro for returning tokens, it makes sense to perform some of the common work there, (such as copying string values). Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Drop extra, final newline from most outputCarl Worth2014-07-29130-165/+51
| | | | | | | | | | | | | | | | | | | | 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 <jordan.l.justen@intel.com>
* glsl/glcpp: Add testing for EOF sans newline (and fix for <DEFINE>, <COMMENT>)Carl Worth2014-07-297-2/+13
| | | | | | | | | | | | | | | | 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 <jordan.l.justen@intel.com>
* glsl/glcpp: Remove some un-needed calls to NEWLINE_CATCHUPCarl Worth2014-07-291-4/+0
| | | | | | | | | | | | | | | | | The NEWLINE_CATCHUP code is only intended to be invoked after we lex an actual newline character ('\n'). The two extra calls here were apparently added accidentally because the pattern happened to contain a (negated) '\n', (see commit 6005e9cb283214cd57038c7c5e7758ba72ec6ac2). I don't think either case could have caused any actual bug. (In the first case, the pattern matched right up to the next newline, so the NEWLINE_CATCHUP code was just about to be called. In the second case, I don't think it's possible to actually enter the <SKIP> start condition after commented newlines without any intervening newline.) But, if nothing else, the code is cleaner without these extra calls. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glsl/glcpp: Add support for comments between #define and macro identifierCarl Worth2014-07-293-2/+41
| | | | | | | | | | | | | | | 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 <jordan.l.justen@intel.com>
* glsl/glcpp: Emit proper error for #define with a non-identifierCarl Worth2014-07-293-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <jordan.l.justen@intel.com>
* 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-292-2/+3
| | | | | | | | | | | | | 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: move macro declaration before code to fix MSVC buildBrian Paul2014-07-101-1/+2
| | | | Reviewed-by: Carl Worth <cworth@cworth.org>
* glsl/glcpp: Don't choke on an empty pragmaCarl Worth2014-07-093-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | 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 <kenneth@whitecape.org>
* glsl/glcpp: Promote "extra token at end of directive" from warning to errorCarl Worth2014-07-093-1/+14
| | | | | | | | | | | | | | | | 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 <kenneth@whitecape.org>
* glsl/glcpp: Once again report undefined macro name in error message.Carl Worth2014-07-093-38/+86
| | | | | | | | | | | 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 <kenneth@whitecape.org>
* glsl/glcpp: Add short-circuiting for || and && in #if/#elif for OpenGL ES.Carl Worth2014-07-094-30/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <kenneth@whitecape.org>
* glsl/glcpp: Fix glcpp to properly lex entire "preprocessing numbers"Carl Worth2014-07-093-0/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <anuj.phogat@gmail.com>
* glsl/glcpp: Fix glcpp to catch garbage after #if 1 ... #elseCarl Worth2014-07-097-16/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <mattst88@gmail.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* 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 <anuj.phogat@gmail.com>
* glsl/glcpp: Fix preprocessor error condition for macro redefinitionAnuj Phogat2014-07-091-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch specifically fixes redefinition condition for white space changes. #define and #undef functionality in GLSL follows the standard for C++ preprocessors for macro definitions. From 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) Fixes Khronos GLES3 CTS tests; invalid_object_whitespace_vertex invalid_object_whitespace_fragment Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Carl Worth <cworth@cworth.org>
* 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 <anuj.phogat@gmail.com>
* glsl/glcpp: Do not allow undefining the built-in macrosAnuj Phogat2014-07-091-0/+6
| | | | | | | | | | | | | | | | | Fixes piglit tests in spec/glsl-es-3.00/compile: undef-__FILE__.vert undef-GL_ES.vert undef-__LINE__.vert undef-__VERSION__.vert Also, fixes Khronos GLES3 CTS tests: undefine_invalid_object_1_vertex undefine_invalid_object_1_fragment undefine_invalid_object_2_vertex undefine_invalid_object_2_fragment Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Carl Worth <cworth@cworth.org>
* glsl: add support for AMD_vertex_shader_viewport_indexIlia Mirkin2014-07-021-0/+3
| | | | | | | Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> Tested-by: Tobias Droste <tdroste@gmx.de>
* Partially revert "glsl: Add builtin define for ARB_fragment_layer_viewport"Chris Forbes2014-06-221-0/+6
| | | | | This partially reverts commit cc18b1ec2161c846109e921d7821dfeef7a06f3a, which dropped some unrelated code due to a fumbled rebase.
* glsl: Add builtin define for ARB_fragment_layer_viewportChris Forbes2014-06-221-6/+3
| | | | | | | | The spec doesn't actually mention adding this, but this is the usual pattern so I'm assuming it's a spec bug. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* glsl: parser changes for GL_ARB_explicit_uniform_locationTapani Pälli2014-06-161-0/+3
| | | | | | | | | | | | Patch adds a preprocessor define for the extension and stores explicit location data for uniforms during AST->HIR conversion. It also sets layout token to be available when having the extension in place. v2: change parser check to require GLSL 330 or enabling GL_ARB_explicit_attrib_location (Ian) v3: fix the check and comment in AST->HIR (Petri) Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
* mesa: Enable GL_EXT_separate_shader_objects for OpenGL ESIan Romanick2014-05-021-0/+1
| | | | | Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
* mesa/sso: Enable GL_ARB_separate_shader_objects by defaultIan Romanick2014-05-021-3/+1
| | | | | Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
* glcpp: Do not remove spaces to preserve locations.Sir Anthony2014-03-084-5/+5
| | | | | | | | | 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 <kenneth@whitecape.org>
* glsl: Update lexers in glsl and glcpp to hande end position of token.Sir Anthony2014-03-081-1/+2
| | | | Reviewed-by: Carl Worth <cworth@cworth.org>
* glsl/sso: Add parser and AST-to-HIR support for separate shader object layoutsIan Romanick2014-02-211-0/+3
| | | | | | | | | | | | GL_ARB_separate_shader_objects adds the ability to specify location layouts for interstage inputs and outputs. In addition, this extension makes 'in' and 'out' generally available for shader inputs and outputs. This mimics the behavior of GL_ARB_explicit_attrib_location. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glcpp: Only warn for macro names containing __Ian Romanick2014-02-192-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <ian.d.romanick@intel.com> Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Tested-by: Darius Spitznagel <d.spitznagel@goodbytez.de> Cc: Tapani Pälli <lemody@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870 Bugzilla: Khronos #11702
* glcpp: Add built-in define for ARB_shader_image_load_store.Francisco Jerez2014-02-121-0/+3
| | | | Reviewed-by: Paul Berry <stereotype441@gmail.com>
* mesa/cs: Add extension enable flags for ARB_compute_shader.Paul Berry2014-02-051-0/+3
| | | | Reviewed-by: Matt Turner <mattst88@gmail.com>
* glcpp: Reject #version after the version has been resolved.Matt Turner2014-01-311-0/+6
| | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74166 Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Carl Worth <cworth@cworth.org>
* glcpp: Rename the variable used to enable debugging.Carl Worth2014-01-311-1/+1
| | | | | | | | The -p option we now use when calling bison means that this variable will be named glcpp_parser_debug not yydebug. This was not caught when the -p option was added because this variable isn't used in the code as committed. (I prefer the declaration to remain since it allows a developer to easily find this variable name to enable debugging.)
* 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 <jordan.l.justen@intel.com>
* glcpp: Don't enter lexer's NEWLINE_CATCHUP start state for single-line commentsCarl Worth2014-01-311-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 6005e9cb28 a new start state of NEWLINE_CATCHUP was added to the lexer. This start state is used whenever the lexer is emitting a NEWLINE token to emit additional NEWLINE tokens for any newline characters that were skipped by an immediately preceding multi-line comment. However, that commit erroneously entered the NEWLINE_CATCHUP state for single-line comments. This is not desired since in the case of a single-line comment, the lexer is not emitting any NEWLINE token. The result is that the lexer will remain in the NEWLINE_CATCHUP state and proceed to fail to emit a NEWLINE token for the subsequent newline character, (since the case to match \n expects only the INITIAL start state). The fix is quite simple, remove the "BEGIN NEWLINE_CATCHUP" code from the single-line comment case, (preserving it only in exactly the cases where the lexer is actually emitting a NEWLINE token). Many thanks to Petri Latvala for reporting this bug and for providing the minimal test case to exercise it. The bug showed up only with a multi-line comment which was followed immediately by a single-line comment (without any intervening newline), such as: /* */ // Kablam! Since 6005e9cb28, and before this commit, that very innocent-looking combination of comments would yield a parse failure in the compiler. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72686 Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* glcpp: Resolve implicit GLSL version to 100 if the API is ES.Matt Turner2014-01-274-5/+16
| | | | | | | | | | Fixes a regression since b2d1c579 where ES shaders without a #version declaration would fail to compile if their precision declaration was wrapped in the standard #ifdef GL_ES check. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74066 Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* glcpp: Check version_resolved in the proper place.Matt Turner2014-01-273-13/+13
| | | | | | | | | | | | | | | | | | The check was in the wrong place, such that if a shader incorrectly put a preprocessor token before the #version declaration, the version would be resolved twice, leading to a segmentation fault when attempting to redefine the __VERSION__ macro. #extension GL_ARB_sample_shading: require #version 130 void main() {} Also, rename glcpp_parser_resolve_version to glcpp_parser_resolve_implicit_version to avoid confusion. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Carl Worth <cworth@cworth.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* glcpp: Make sure GL_AMD_shader_trinary_minmax is definedIan Romanick2014-01-271-3/+2
| | | | | | | | | | | The define was only available if gl_extensions::AMD_shader_trinary_minmax was set, but no driver set it. Since the extension is advertised by default, remove that field too. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Cc: Maxence Le Doré <maxence.ledore@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
* glcpp: Define GL_EXT_shader_integer_mix in both GL and ES.Matt Turner2014-01-231-3/+5
| | | | | Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* glcpp: Remove unused gl_api bits.Matt Turner2014-01-232-2/+0
| | | | Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* glcpp: Set extension defines after resolving the GLSL version.Matt Turner2014-01-233-143/+172
| | | | | | | | | | | | | | | | | | | | | | Instead of defining preprocessor macros in glcpp_parser_create based on the GL API, wait until the shader version has been resolved. Doing this allows us to correctly set (and not set) preprocessor macros for extensions allowed by the API but not the shader, as in the case of ARB_ES3_compatibility. The shader version has been resolved when the preprocessor encounters the first preprocessor token, since the GLSL spec says "The #version directive must occur in a shader before anything else, except for comments and white space." Specifically, if a #version token is found the version is known explicitly, and if any other preprocessor token is found then the GLSL version is implicitly 1.10. Cc: mesa-stable@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71630 Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* mesa: Add ARB_arrays_of_arraysTimothy Arceri2014-01-231-0/+3
| | | | | Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* glsl: Add extension infrastructure for ARB_viewport_arrayIan Romanick2014-01-201-0/+3
| | | | | Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
generated by cgit v1.1 at 2025-08-05 04:14:44 +0000