mesa/src/compiler/glsl/glcpp
Matt Turner 0201fc95e7 glcpp: Handle bison-3.6 error message changes
In bison's commit 72c9fa4510eb (skeletons: use "end of file" instead of
"$end") in bison-3.6, '$end' was changed to 'end of file' in error
messages. Since our glcpp test cases contain the expected output text,
they rely on the particular messages printed by bison. The test case
084-unbalanced-parentheses fails when Mesa is built with bison-3.6 due
to this change.

To allow the test to pass on all supported versions of bison, we:

   1. Change '$end' -> 'end of file' in the .expected file, and
   2. Normalize the error generated by the test case with the same
      replacement

Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3181
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7659>
(cherry picked from commit df29d0a111)
2020-11-19 10:11:06 -08:00
..
tests glcpp: Handle bison-3.6 error message changes 2020-11-19 10:11:06 -08:00
glcpp-lex.l glsl: add preprocessor #include support 2019-11-20 05:05:55 +00:00
glcpp-parse.y glsl: add extra pp tokens workaround and enable for CoR 2020-10-29 23:35:58 +00:00
glcpp.c Fix scons build 2018-04-12 19:55:01 -04:00
glcpp.h glsl: add preprocessor #include support 2019-11-20 05:05:55 +00:00
meson.build glsl/test: Don't run whitespace tests in parallel 2020-08-17 17:44:26 +00:00
pp.c glsl: pass gl_context to glcpp_parser_create() 2019-11-20 05:05:55 +00:00
pp_standalone_scaffolding.c mesa: add support cursor support for relative path shader includes 2019-11-20 05:05:56 +00:00
pp_standalone_scaffolding.h mesa: add support cursor support for relative path shader includes 2019-11-20 05:05:56 +00:00
README glsl: move to compiler/ 2016-01-26 16:08:33 +00:00

glcpp -- GLSL "C" preprocessor

This is a simple preprocessor designed to provide the preprocessing
needs of the GLSL language. The requirements for this preprocessor are
specified in the GLSL 1.30 specification availble from:

http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.30.10.pdf

This specification is not precise on some semantics, (for example,
#define and #if), defining these merely "as is standard for C++
preprocessors". To fill in these details, I've been using a draft of
the C99 standard as available from:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

Any downstream compiler accepting output from glcpp should be prepared
to encounter and deal with the following preprocessor macros:

	#line
	#pragma
	#extension

All other macros will be handled according to the GLSL specification
and will not appear in the output.

Known limitations
-----------------
A file that ends with a function-like macro name as the last
non-whitespace token will result in a parse error, (where it should be
passed through as is).