mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2025-12-24 21:50:12 +01:00
d3df641f0a
The GLSL specification is vague here, (just says "as is standard for C++"), though the C specifications seem quite clear that this should be an error. However, an existing piglit test (CorrectPreprocess11.frag) expects this to be a warning, not an error, so we change this, and document in README the deviation from the specification. |
||
|---|---|---|
| .. | ||
| tests | ||
| .gitignore | ||
| glcpp-lex.c | ||
| glcpp-lex.l | ||
| glcpp-parse.c | ||
| glcpp-parse.h | ||
| glcpp-parse.y | ||
| glcpp.c | ||
| glcpp.h | ||
| Makefile.am | ||
| pp.c | ||
| 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).
Known deviations from the specification
---------------------------------------
As mentoned above, the GLSL specification (as of 1.30.10) is fairly
vague on some aspects of the preprocessor, and we've been using C99 to
fill in details. Here is a list of cases where we have deviated from
the behavior specified in C99 to obtain better compatibility with
other GLSL implementations:
* Redefining a macro with a different value
C89 says that a macro "may be redefined ... provided that the
second definition [is equivalent]" (Section 3.8.3 Macro
Replacement/constraints)
C99 is even more explicit, saying tthat a macro "shall not be
redefined by another #define preprocessing directive unless the
second definition [is equivalent]" (Section 6.10.3 Macro
Replacement/Constraints)
In spite of this, glcpp emits a warning rather than an error for
non-equivalent redefinition of macros since this matches the
behavior of other, widely-used implementations.