eb26f0d5b6
Matching the newline here meant having to do some redundant work here, (incrementing line number, resetting column number, and returning a NEWLINE token), that could otherwise simply be left to the existing rule which matches a newline. Worse, when the comment rule matches the newline as well, the parser can lookahead and see a token for something that should actually be skipped. For example, in a case like this: #if 0 // comment here fail #else win #endif Both fail and win appear in the output, (not that the condition is being evaluated incorrectly---merely that one token after the comment's newline was being lexed/parse regardless of the condition). This commit fixes the above test case, (which is also remarkably similar to 087-if-comments which now passes).
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.08.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 the C99 standard (for which I had a convenient copy) as available from: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf Known limitations ----------------- Macro invocations cannot include embedded newlines. The __LINE__, __FILE__, and __VERSION__ macros are not yet supported. The argument of the 'defined' operator cannot yet include enclosing parentheses. The #error, #pragma, #extension, #version, and #line 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).