mesa/src/glsl/glcpp
Matt Turner 3e0e9e3bf9 glcpp: Check version_resolved in the proper place.
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>
2014-01-27 21:15:35 -08:00
..
tests glcpp: error on multiple #else/#elif directives 2014-01-02 14:22:58 -08:00
.gitignore glcpp: Add back tests/*.out to .gitignore 2013-01-11 11:49:33 +01:00
glcpp-lex.l glcpp: Replace multi-line comment with a space (even as part of macro definition) 2014-01-02 14:15:51 -08:00
glcpp-parse.y glcpp: Check version_resolved in the proper place. 2014-01-27 21:15:35 -08:00
glcpp.c glcpp: Remove unused gl_api bits. 2014-01-23 11:33:22 -08:00
glcpp.h glcpp: Check version_resolved in the proper place. 2014-01-27 21:15:35 -08:00
pp.c glcpp: Check version_resolved in the proper place. 2014-01-27 21:15:35 -08:00
README glcpp: Update README for new support of __LINE__ and __FILE__. 2012-11-29 13:03:02 -08: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).