mesa/src/glsl/glcpp at ad8eec9eec2fe9577dca1051ea3c175babaaa38c - NeroReflex/mesa

History

Carl Worth cd2e2187cb glsl: Avoid ralloc_stealing a long-lived object to a short-lived parent In commit `6ecee54a9a` a call to talloc_reference was replaced with a call to talloc_steal. This was in preparation for moving to ralloc which doesn't support reference counting. The justification for talloc_steal within token_list_append in that commit is that the tokens are being copied already. But the copies are shallow, so this does not work. Fortunately, the lifetime of these tokens is easy to understand. A token list for "replacements" is created and stored in a hash table when a function-like macro is defined. This list will live until the macro is #undefed (if ever). Meanwhile, a shallow copy of the list is created when the macro is used and the list expanded. This copy is short-lived, so is unsuitable as a new parent. So we can just let the original, longer-lived owner continue to own the underlying objects and things will work. This fixes bug #45082: "ralloc.c:78: get_header: Assertion `info->canary == 0x5A1106' failed." when using a macro in GLSL https://bugs.freedesktop.org/show_bug.cgi?id=45082 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> NOTE: This is a candidate for stable release branches.		2012-02-02 12:05:21 -08:00
..
tests	glsl: Add glcpp tests for a macro used twice	2012-02-02 12:05:21 -08:00
.gitignore	Revert "automake: src/glsl and src/glsl/glcpp"	2012-01-31 21:33:59 -05:00
glcpp-lex.l	glcpp: Fix so that trailing punctuation does not prevent macro expansion	2012-02-02 12:05:21 -08:00
glcpp-parse.y	glsl: Avoid ralloc_stealing a long-lived object to a short-lived parent	2012-02-02 12:05:21 -08:00
glcpp.c
glcpp.h
pp.c
README

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).