![]() The glcpp parser is line-based, so it needs to see a NEWLINE token at the end of each line. This causes a trick for files that end without a final newline. Previously, the lexer for glcpp punted in this case by unconditionally returning a NEWLINE token at end-of-file, (causing most files to have an extra blank line at the end). Here, we refine this by lexing end-of-file as a NEWLINE token only if the immediately preceding token was not a NEWLINE token. The patch is a minor change that only looks huge for two reasons: 1. Almost all glcpp test result ".expected" files are updated to drop the extra newline. 2. All return statements from the lexer are adjusted to use a new RETURN_TOKEN macro that tracks the last-token-was-a-newline state. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> |
11 years ago | |
---|---|---|
.. | ||
tests | glsl/glcpp: Drop extra, final newline from most output | 11 years ago |
.gitignore | glcpp: Add back tests/*.out to .gitignore | 12 years ago |
README | glcpp: Update README for new support of __LINE__ and __FILE__. | 13 years ago |
glcpp-lex.l | glsl/glcpp: Drop extra, final newline from most output | 11 years ago |
glcpp-parse.y | glsl/glcpp: Drop extra, final newline from most output | 11 years ago |
glcpp.c | glcpp: Rename the variable used to enable debugging. | 11 years ago |
glcpp.h | glsl/glcpp: Drop extra, final newline from most output | 11 years ago |
pp.c | glcpp: Resolve implicit GLSL version to 100 if the API is ES. | 11 years ago |
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).