mesa/src/glsl/glcpp at 7ab1c7f7926c75a07f33eb149d0fc17dcfaffd5e - NeroReflex/mesa

History

Carl Worth 7ab1c7f792 glcpp: Fix so that trailing punctuation does not prevent macro expansion The trick here is that flex always chooses the rule that matches the most text. So with a input text of "two:" which we want to be lexed as an IDENTIFIER token "two" followed by an OTHER token ":" the previous OTHER rule would match longer as a single token of "two:" which we don't want. We prevent this by forcing the OTHER pattern to never match any characters that appear in other constructs, (no letters, numbers, #, _, whitespace, nor any punctuation that appear in CPP operators). Fixes bug #44764: GLSL preprocessor doesn't replace defines ending with ":" https://bugs.freedesktop.org/show_bug.cgi?id=44764 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> NOTE: This is a candidate for stable release branches.		2012-02-02 12:05:21 -08:00
..
tests	glcpp: Add new test showing bug where a trailing ':' prevents macro expansion	2012-02-02 12:05:21 -08:00
.gitignore	Revert "automake: src/glsl and src/glsl/glcpp"	2012-01-31 21:33:59 -05:00
glcpp-lex.l	glcpp: Fix so that trailing punctuation does not prevent macro expansion	2012-02-02 12:05:21 -08:00
glcpp-parse.y	mesa: rename the AMD_conservative_depth extension flag to ARB	2011-11-22 20:56:50 +01:00
glcpp.c	glsl: Silence several "warning: unused parameter"	2011-09-09 12:01:50 -07:00
glcpp.h
pp.c
README

README

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 handles according to the GLSL specification
and will not appear in the output.

Known limitations
-----------------
The __LINE__ and __FILE__ macros are not yet supported.

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).