With two tests both numbered 118, there was a confusing off-by-two difference
between the last test number and the total number of tests (as reported by
glcpp-test).
With this rename, there's only an off-by-one difference left, (which is easy
to understand given the zero-based test numbering).
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Here is some additional stress testing of nested macros where the expansion
of macros involves commas, (and whether those commas are interpreted as
argument separators or not in subsequent function-like macro calls).
Credit to the GCC documentation that directed my attention toward this issue:
https://gcc.gnu.org/onlinedocs/gcc-3.2/cpp/Argument-Prescan.html
Fixing the bug required only removing code from glcpp. When first testing the
details of expansions involving commas, I had come to the mistaken conclusion
that an expanded comma should never be treated as an argument separator, (so
had introduced the rather ugly COMMA_FINAL token to represent this).
In fact, an expanded comma should be treated as a separator, (as tested here),
and this treatment can be avoided by judicious use of parentheses (as also
tested here).
With this simple removal of the COMMA_FINAL token, the behavior of glcpp
matches that of gcc's preprocessor for all of these hairy cases.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Beyond just listing this in the TESTS variable in Makefile.am, only minor
changes were needed to make this work. The primary issue is that the build
system runs the test script from a different directory than the script
itself. So we have to use the $srcdir variable to find the test input files.
Using $srcdir in this way also ensures that this test works when using an
out-of-tree build.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The (optional) test-specific command-line arguments to be passed to glcpp are
embedded within the source files of some tests, and glcpp-test uses grep to
extract them.
Of course, grep is line-based and looks for the native line-separator to
determine line boundaries. So, for files using non-native line separators,
grep was getting quite confused and passing bogus arguments to glcpp.
Fix this by canonical-izing the line separators in the source file prior to
using grep.
With this commit, the glcpp-test-cr-lf tests pass entirely:
\r: 143/143 tests pass
\r\n: 143/143 tests pass
\n\r: 143/143 tests pass
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Sometimes the newline separator is a single character, and sometimes it is two
characters. Before we can fold away and line-continuation backslashes, we
identify the flavor of line separator that is in use.
With this identified, we then correctly search for backslashes followed
immediately by the first character of the line separator.
Also, when re-inserting newlines to replace collapsed newlines, we carefully
insert newlines of the same flavor.
With this commit, almost all remaining test are fixed as tested by
glcpp-test-cr-lf:
\r: 142/143 tests pass
\r\n: 142/143 tests pass
\n\r: 143/143 tests pass
(The only remaining failures have nothing to do with the actual pre-processor
code, but are due to a bug in the way the test suite uses grep to try to
extract test-specific command-line options from the source files.)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Some tests were failing because the message printed by #error was including a
'\r' character from the source file in its output.
This is easily avoided by fixing the regular expression for #error to never
include any of the possible newline characters, (neither '\r' nor '\n').
With this commit 2 tests are fixed for each of the '\r' and '\r\n' cases.
Current results after the commit are:
\r: 137/143 tests pass
\r\n 142/143 tests pass
\n\r: 139/143 tests pass
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The GLSL specification says that either carriage-return, line-feed, or both
together can be used to terminate lines. Further, it says that when used
together, the pair of terminators shall be interpreted as a single line.
This final requirement has not been respected by glcpp up until now, (it has
been emitting two newlines for every CR+LF pair).
Here, we fix the lexer by using a regular expression for NEWLINE that eats
up both "\r\n" (or even "\n\r") if possible before also considering a single
'\n' or a single '\r' as a line terminator.
Before this commit, the test results are as follows:
\r: 135/143 tests pass
\r\n: 4/143 tests pass
\n\r: 4/143 tests pass
After this commit, the test results are as follows:
\r: 135/143 tests pass
\r\n: 140/143 tests pass
\n\r: 139/143 tests pass
So, obviously, a dramatic improvement.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The GLSL specification has a very broad definition of what is a
newline. Namely, it can be the carriage-return character, '\r', the newline
character, '\n', or any combination of the two, (though in combination, the
two are treated as a single newline).
Here, we add a new test-runner, glcpp-test-cr-lf, that, for each possible
line-termination combination, runs through the existing test suite with all
source files modified to use those line-termination characters. Instead of
using the .expected files for this, this script assumes that the regular test
suite has been run already and expects the output to match the .out
files. This avoids getting 4 test failures for any one bug, and instead will
hopefully only report bugs actually related to the line-termination
characters.
The new testing is not yet integrated into "make check". For that, some
munging of the testdir option will be necessary, (to support "make check" with
out-of-tree builds). For now, the scripts can just be run directly by hand.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Prior to this commit, the following snippet would trigger an error in glcpp:
#define FOO defined BAR
#if FOO
#endif
The problem was that support for the "defined" operator was implemented within
the grammar, (where the parser was parsing the tokens of the condition
itself). But what is required is to interpret the "defined" operator that
results after macro expansion is performed.
I could not find any fix for this case by modifying the grammar alone. The
difficulty is that outside of the grammar we already have a recursive function
that performs macro expansion (_glcpp_parser_expand_token_list) and that
function itself must be augmented to be made aware of the semantics of the
"defined" operator.
The reason we can't simply handle "defined" outside of the recursive expansion
function is that not only must we scan for any "defined" operators in the
original condition (before any macro expansion occurs); but at each level of
the recursive expansion, we must again scan the list of tokens resulting from
expansion and handle "defined" before entering the next level of recursion to
further expand macros.
And of course, all of this is context dependent. The evaluation of "defined"
operators must only happen when we are handling preprocessor conditionals,
(#if and #elif) and not when performing any other expansion, (such as in the
main body).
To implement this, we add a new "mode" parameter to all of the expansion
functions to specify whether resulting DEFINED tokens should be evaluated or
ignored.
One side benefit of this change is that an ugly wart in the grammar is
removed. We previously had "conditional_token" and "conditional_tokens"
productions that were basically copies of "pp_token" and "pp_tokens" but with
added productions for the various forms of DEFINED operators. With the new
code here, those ugly copy-and-paste productions are eliminated from the
grammar.
A new "make check" test is added to stress-test the code here.
This commit fixes the following Khronos GLES3 CTS tests:
conditional_inclusion.basic_2_vertex
conditional_inclusion.basic_2_fragment
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, we were passing these through, just like any other pragma. But the
downstream compiler was tripping up on them. It seems easier to swallow these
in the preprocessor and not pass them on at all rather than fixing the
downstream compiler.
This fixes the following Khronos GLES3 CTS tests:
preprocessor.pragmas.pragma_vertex
preprocessor.pragmas.pragma_fragment
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, the #pragma directive was swallowing an entire line, (including
the final newline). At that time it was appropriate for it to increment the
line count.
More recently, our handling of #pragma changed to not include the newline. But
the code to increment yylineno stuck around. This was causing __LINE__ to be
increased by one more than desired for every #pragma.
Remove the bogus, extra increment, and add a test for this case.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This new "make check" test stresses out the support from the last two commits,
(to esnure that '#' is correctly interpreted as the null directives,
regardless of any whitespace or comments on the same line).
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This is the fix for the following line:
# // comment to ignore here
According to the translation-phase rules, the comment should be removed before
the preprocessor looks to interpret the null directive.
So in our implementation we must explicitly look for single-line comments in
the <HASH> start condition as well.
This commit fixes the following Khronos GLES3 CTS tests:
null_directive_vertex
null_directive_fragment
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This simply tests the previous commit, (that #define followed by a comment
will still generate the expected "#define without macro name" error message).
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We were already correctly supporting single-line comments in case like:
#define FOO bar // comment here...
The new support added here is simply for the none-too-useful:
#define // comment instead of macro name
With this commit, this line will now give the expected "#define without
macro name" error message instead of the lexer just going off into the
weeds.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This ensures that the previous commit indeed generates the expected error
message when a "#define" directive is not followed by anything except for a
newline.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, glcpp would emit an error like this if <EOF> happened to occur
immediately after the "#define", but in general would just get confused,
(leading to un-helpful error messages).
To fix things to generate a clean error message, we do a few things:
1. Don't require horizontal whitespace immediately after #define
2. Add a production for the error case, (DEFINE_TOKEN followed
immediately by a NEWLINE token).
3. Make the lexer reset to the <INITIAL> state after every NEWLINE.
This 3rd point prevents the lexer from getting so confused and generating
further spurious errors in the file because it was stuck in the <DEFINE> start
condition.
We also drop the similar error message from the <EOF> rule since the
newly-added rule will have already printed the error message.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Current version can create ir_expression where operands have
different base type, patch adds support for unsigned type.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
https://bugs.freedesktop.org/show_bug.cgi?id=80880
Previously we had to keep unreachable global symbols in the symbol table
because the symbol table is used during linking. Having the symbol
table retain pointers to freed memory... what could possibly go wrong?
At the same time, this meant that we kept live references to tons of
memory that was no longer needed.
New strategy: destroy the old symbol table, and make a new one from the
reachable symbols.
Valgrind massif results for a trimmed apitrace of dota2:
n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B)
Before (32-bit): 59 40,642,425,451 76,337,968 69,720,886 6,617,082 0
After (32-bit): 46 40,661,487,174 75,116,800 68,854,065 6,262,735 0
Before (64-bit): 79 37,179,441,771 106,986,512 98,112,095 8,874,417 0
After (64-bit): 64 37,200,329,700 104,872,672 96,514,546 8,358,126 0
A real savings of 846KiB on 32-bit and 1.5MiB on 64-bit.
v2: (by Kenneth Graunke) Just add the ir_function from the IR stream,
rather than looking it up in the symbol table; they're now
identical.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Piglit's spec/glsl-1.10/linker/override-builtin-{const,uniform}-05 tests
do the following:
1. Call abs(float) - a built-in function.
2. Create a user-defined replacement for abs(float).
3. Call abs(float) again - now the user function.
At step 1, we created an ir_function which included the built-in
signature, added it to the symbol table, and emitted it into the IR
stream.
Then, when processing the function definition at step 2, we'd see that
there was already an ir_function. But, since there were no user-defined
functions, we skipped over a bunch of code, and ended up creating a
second one. This new ir_function shadowed the original in the symbol
table, but both ended up in the IR stream.
This results in an awkward situation where searching for an ir_function
via the symbol table, a forward linked list walk, and a reverse linked
list walk may return different ir_functions. This seems undesirable.
This patch instead re-uses the existing ir_function, putting both
built-in and user-defined signatures in the same one. The previous
patch's additional filtering ensures everything continues working.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Historically, we've implemented the rules for overriding built-in
functions by creating multiple ir_functions and relying on the symbol
table to hide the one containing built-in functions. That works, but
has a few drawbacks, so the next patch will change it.
Instead, we'll have a single ir_function for a particular name, which
will contain both built-in and user-defined signatures. Passing an
extra parameter to matching_signature makes it easy to ignore built-ins
when they're supposed to be hidden.
I didn't add the parameter to exact_matching_signature since it wasn't
necessary.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This code was attemping to align the base of the structure to the required
alignment of the structure. However, it had two problems:
1. It was aligning the target structure member, not the base of the
structure.
2. It was calculating the alignment based on the members previous to the
target member instead of all the members of the structure.
Fixes gles3conform failures in:
ES3-CTS.shaders.uniform_block.random.nested_structs.6
ES3-CTS.shaders.uniform_block.random.nested_structs_arrays_instance_arrays.2
ES3-CTS.shaders.uniform_block.random.nested_structs_arrays_instance_arrays.6
ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.5
ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.19
ES3-CTS.shaders.uniform_block.random.all_shared_buffer.0
ES3-CTS.shaders.uniform_block.random.all_shared_buffer.2
ES3-CTS.shaders.uniform_block.random.all_shared_buffer.6
ES3-CTS.shaders.uniform_block.random.all_shared_buffer.12
v2: Fix rebase failure noticed by Matt.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Use the data that is stored in the ir_variable and the glsl_type to
determine whether or not a UBO member is row-major.
Fixes gles3conform failures in:
ES3-CTS.shaders.uniform_block.instance_array_basic_type.shared.row_major_mat2
ES3-CTS.shaders.uniform_block.instance_array_basic_type.shared.row_major_mat3
ES3-CTS.shaders.uniform_block.instance_array_basic_type.shared.row_major_mat4
ES3-CTS.shaders.uniform_block.instance_array_basic_type.shared.row_major_mat2x3
ES3-CTS.shaders.uniform_block.instance_array_basic_type.shared.row_major_mat2x4
ES3-CTS.shaders.uniform_block.instance_array_basic_type.shared.row_major_mat3x2
ES3-CTS.shaders.uniform_block.instance_array_basic_type.shared.row_major_mat3x4
ES3-CTS.shaders.uniform_block.instance_array_basic_type.shared.row_major_mat4x2
ES3-CTS.shaders.uniform_block.instance_array_basic_type.shared.row_major_mat4x3
ES3-CTS.shaders.uniform_block.instance_array_basic_type.packed.row_major_mat2
ES3-CTS.shaders.uniform_block.instance_array_basic_type.packed.row_major_mat3
ES3-CTS.shaders.uniform_block.instance_array_basic_type.packed.row_major_mat4
ES3-CTS.shaders.uniform_block.instance_array_basic_type.packed.row_major_mat2x3
ES3-CTS.shaders.uniform_block.instance_array_basic_type.packed.row_major_mat2x4
ES3-CTS.shaders.uniform_block.instance_array_basic_type.packed.row_major_mat3x2
ES3-CTS.shaders.uniform_block.instance_array_basic_type.packed.row_major_mat3x4
ES3-CTS.shaders.uniform_block.instance_array_basic_type.packed.row_major_mat4x2
ES3-CTS.shaders.uniform_block.instance_array_basic_type.packed.row_major_mat4x3
ES3-CTS.shaders.uniform_block.instance_array_basic_type.std140.row_major_mat2
ES3-CTS.shaders.uniform_block.instance_array_basic_type.std140.row_major_mat3
ES3-CTS.shaders.uniform_block.instance_array_basic_type.std140.row_major_mat4
ES3-CTS.shaders.uniform_block.instance_array_basic_type.std140.row_major_mat2x3
ES3-CTS.shaders.uniform_block.instance_array_basic_type.std140.row_major_mat2x4
ES3-CTS.shaders.uniform_block.instance_array_basic_type.std140.row_major_mat3x2
ES3-CTS.shaders.uniform_block.instance_array_basic_type.std140.row_major_mat3x4
ES3-CTS.shaders.uniform_block.instance_array_basic_type.std140.row_major_mat4x2
ES3-CTS.shaders.uniform_block.instance_array_basic_type.std140.row_major_mat4x3
ES3-CTS.shaders.uniform_block.random.nested_structs_arrays.2
ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.5
ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.9
Causes gles3conform failures in:
ES3-CTS.shaders.uniform_block.random.basic_types.8
ES3-CTS.shaders.uniform_block.random.basic_arrays.3
ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.0
ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.2
ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.13
ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.18
ES3-CTS.shaders.uniform_block.random.all_shared_buffer.4
These failures will be fixed shortly.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fixes gles3conform failures in:
ES3-CTS.shaders.uniform_block.random.nested_structs_arrays_instance_arrays.3
ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.13
Causes gles3conform failures in:
ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.9
This failure will be fixed shortly.
v2: Use without_array() instead of older predicates.
v3: s/GLSL_MATRIX_LAYOUT_DEFAULT/GLSL_MATRIX_LAYOUT_INHERITED/g
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
v2: Rename GLSL_MATRIX_LAYOUT_DEFAULT to GLSL_MATRIX_LAYOUT_INHERITED.
Add comments in glsl_types.h explaining the layouts. Suggested by Matt.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This causes the thing following the structure to be vec4-aligned.
Fixes gles3conform failures in:
ES3-CTS.shaders.uniform_block.random.nested_structs.2
ES3-CTS.shaders.uniform_block.random.all_shared_buffer.5
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
I also considered renaming visit_field(const glsl_struct_field *) to
entry_record and adding an exit_record method. This would be more
similar to the hierarchical visitor.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Commit 32f32292 (glsl: Allow elimination of uniform block members)
enabled elimination of unused uniform block members to fix a gles3
conformance test failure. This went too far the other way.
Section 2.11.6 (Uniform Variables) of the OpenGL ES 3.0.3 spec says:
"All members of a named uniform block declared with a shared or
std140 layout qualifier are considered active, even if they are not
referenced in any shader in the program. The uniform block itself is
also considered active, even if no member of the block is
referenced."
Fixes gles3conform failures in:
ES3-CTS.shaders.uniform_block.single_nested_struct.per_block_buffer_shared
ES3-CTS.shaders.uniform_block.single_nested_struct.per_block_buffer_std140
ES3-CTS.shaders.uniform_block.single_nested_struct_array.per_block_buffer_shared
ES3-CTS.shaders.uniform_block.single_nested_struct_array.per_block_buffer_std140
ES3-CTS.shaders.uniform_block.random.scalar_types.2
ES3-CTS.shaders.uniform_block.random.scalar_types.9
ES3-CTS.shaders.uniform_block.random.vector_types.1
ES3-CTS.shaders.uniform_block.random.vector_types.3
ES3-CTS.shaders.uniform_block.random.vector_types.7
ES3-CTS.shaders.uniform_block.random.vector_types.9
ES3-CTS.shaders.uniform_block.random.basic_types.5
ES3-CTS.shaders.uniform_block.random.basic_types.6
ES3-CTS.shaders.uniform_block.random.basic_arrays.0
ES3-CTS.shaders.uniform_block.random.basic_arrays.2
ES3-CTS.shaders.uniform_block.random.basic_arrays.5
ES3-CTS.shaders.uniform_block.random.basic_arrays.8
ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.0
ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.4
ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.5
ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.6
ES3-CTS.shaders.uniform_block.random.basic_instance_arrays.9
ES3-CTS.shaders.uniform_block.random.nested_structs.0
ES3-CTS.shaders.uniform_block.random.nested_structs.1
ES3-CTS.shaders.uniform_block.random.nested_structs_arrays.4
ES3-CTS.shaders.uniform_block.random.nested_structs_instance_arrays.8
ES3-CTS.shaders.uniform_block.random.nested_structs_arrays_instance_arrays.7
ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.3
ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.6
ES3-CTS.shaders.uniform_block.random.all_shared_buffer.18
v2: Whitespace and other minor fixes suggested by Matt.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Returns the type without any arrays.
This will be used in later patches in this series.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Suggested-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Just a few lines earlier we may have wrapped the index expression with
ir_unop_i2u expression. Whenever that happens, as_constant will return
NULL, and that almost always happens.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
This gathers macros that have been included across components into util so
that the include chain can be more vertical. In particular, this makes
util stand on its own without any dependence whatsoever on the rest of
mesa.
Signed-off-by: "Jason Ekstrand" <jason.ekstrand@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This hash table is used in core Mesa, the GLSL compiler, and the i965
driver, which makes it a good candidate for the new src/util module.
It's much faster than program/hash_table.[ch] (see commit 6991c2922f
for data), and José's u_hash_table.c has a comment saying Gallium should
probably consider switching to a linear probing hash table at some point.
So this seems like the best candidate for a shared data structure.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
v2 (Jason Ekstrand): Pick up another hash_table use and patch up scons
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
For a long time, we've wanted a place to put utility code which isn't
directly tied to Mesa or Gallium internals. This patch creates a new
src/util directory for exactly that purpose, and builds the contents as
libmesautil.la.
ralloc seemed like a good first candidate. These days, it's directly
used by mesa/main, i965, i915, and r300g, so keeping it in src/glsl
didn't make much sense.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
v2 (Jason Ekstrand): More realloc uses and some scons fixes
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This patch fixes regressions caused by commit 48deb4d. Regressions
happened because 'run_default' var did not get initialized when default
case was the last one.
Now all the switch tests in es3conform suite are passing.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81857
Define the macro GL_OES_standard_derivatives as 1 if the extension
GL_OES_standard_derivatives is supported.
V2 [Chris]: Correct trailing whitespace
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
ERROR is a #define in the MSVC WinGDI.h header file.
Add the _TOKEN suffix as we do for a few other lexer tokens.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We've had bugs in the past where we have been inadvertently matching the
default rule.
Just as we did in the pre-processor in the previous commit, we can use:
%option warn nodefault
in the compiler to instruct flex to not generate the default rule, and
further to warn if our set of rules could let any characters go unmatched.
With this warning active, flex actually warns that the catch-all rule we
recently added to the compiler could never be matched. Since that is all
safely determined at compile time now, we can safely drop this run-time
compiler error message, (as we do in this commit).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
We've had multiple bugs in the past where we have been inadvertently matching
the default rule, (which we never want to do). We recently added a catch-all
rule to avoid this, (and made this rule robust for future start conditions).
Kristian pointed out that flex allows us to go one step better. This syntax:
%option warn nodefault
instructs flex to not generate the default rule at all. Further, flex will
generate a warning at compile time if the set of rules we provide are
inadequate, (such that it would be possible for the default rule to be
matched).
With this warning in place, I found that the catch-all rule was in fact
missing something. The catch-all rule uses a pattern of "." which doesn't
match newlines. So here we extend the newline-matching rule to all start
conditions. That is enough to convince flex that it really doesn't need
any default rule.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Using a single rule here means that we can use the <*> syntax to match
all start conditions. This makes the catch-all rule more robust against
the addition of future start conditions, (no need to maintain an ever-
growing list of start conditions for this rul).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
There is no behavioral change here. It's just easier to verify that lists
of start conditions include all expected conditions when they appear in a
consistent order.
The <INITIAL> state is special, so it appears first in all lists. All others
appear in alphabetical order.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
In some of the recent glcpp bug-fixing, we found that glcpp was emitting
unrecognized characters from the input source file to stdout, and dropping
them from the source passed onto the compiler proper.
This was obviously confusing, and totally undesired.
The bogus behavior comes from an implicit default rule in flex, which is
that any unmatched character is implicitly matched and printed to stdout.
To avoid this implicit matching and printing, here we add an explicit
catch-all rule. If this rule ever matches it prints an internal compiler
error. The correct response for any such error is fixing glcpp to handle
the unexpected character in the correct way.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Previously, the '\r' character was not explicitly matched by any lexer
rule. This means that glcpp would have been using the default flex rule to
match '\r' characters, (where they would have been printed to stdout rather
than actually correctly handled).
With this commit, we treat '\r' as equivalent to '\n'. This is clearly an
improvement the bogus printing to stdout. The resulting behavior is compliant
with the GLSL specification for any source file that uses exclusively '\r' or
'\n' to separate lines.
For shaders that use a multiple-character line separator, (such as "\r\n"),
glcpp won't be precisely compliant with the specification, (treating these as
two newline characters rather than one), but this should not introduce any
semantic changes to the shader programs.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This test is written to exercise a bug which I recently wrote, (but
fortunately caught and fixed before ever committing it).
For the curious:
The bug happened when the NEWLINE_CATCHUP code didn't actually return the
NEWLINE token (due to the skipping). This resulted in the lexer continuing
on through all the subsequent rules while still in the NEWLINE_CATCHUP start
condition, (which then triggered the internal-compiler-error catch-all
rule).
What is intended is for the return of the NEWLINE token to start a new
iteration of the lexer loop, at which time the NEWLINE_CATCHUP-handling code
will reset from the <NEWLINE_CATCHUP> to the <INITIAL> start condition.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
At one point while rewriting the lexing rule for pre-processing numbers, I
made it a bit too aggressive and within a replacement list sucked up a
parameter name that appeared immediately after a period. This caused the
parameter name to be unreplaced when the macro was expanded.
It was in some piglit tests that I originally found this issue. Here, I'm
adding a test to "make check" to ensure that this behavior remains correct.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These operators aren't defined for preprocessor expressions, so we never
implemented them. This led them to be misinterpreted as strings of unary
'+' or '-' operators.
In fact, what is actually desired is to generate an error if these operators
appear in any preprocessor condition.
So this commit looks like it is strictly adding support for these
operators. And it is supporting them as far as passing them through to the
subsequent compiler, (which was already happening anyway).
What's less apparent in the commit is that with these tokens now being lexed,
but with no change to the grammar for preprocessor expressions, these
operators will now trigger errors there.
A new "make check" test is added to verify the desired behavior.
This commit fixes the following Khronos GLES3 CTS test:
invalid_op_1_vertex
invalid_op_1_fragment
invalid_op_2_vertex
invalid_op_2_fragment
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This will emit an error for something like:
#define FOO(x,x) ...
Obviously, it's not a legal thing to do, and it's easy to check.
Add a "make check" test for this as well.
This fixes the following Khronos GLES3 CTS tests:
invalid_function_definitions.unique_param_name_vertex
invalid_function_definitions.unique_param_name_fragment
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
