Files
third_party_mesa3d/src/glsl/glcpp
Carl Worth 28842c2331 glcpp: Implement token pasting for non-function-like macros
This is as simple as abstracting one existing block of code into a
function call and then adding a single call to that function for the
case of a non-function-like macro.

This fixes the recently-added 097-paste-with-non-function-macro test
as well as the following piglit tests:

	spec/glsl-1.30/preprocessor/concat/concat-01.frag
	spec/glsl-1.30/preprocessor/concat/concat-02.frag

Also, the concat-04.frag test now passes for the right reason. The
test is intended to fail the compilation, but before this commit it
was failing compilation (and hence passing the test) for the wrong
reason.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Carl Worth <cworth@cworth.org>
2011-09-30 11:44:10 -07: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 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).