mesa/src/compiler/glsl/glcpp at e7220d2c22b55b8305e5338b80483a6659fb15c8 - mesa

Files

T

Thomas Helland e7220d2c22 glcpp: Use string_buffer for line continuation removal

Migrate removal of line continuations to string_buffer. Before this
it used ralloc_strncat() to append strings, which internally
each time calculates strlen() of its argument. Its argument is
entire shader, so it multiple time scans the whole shader text.

Signed-off-by: Vladislav Egorov <vegorov180@gmail.com>
Tested-by: Dieter Nützel <Dieter at nuetzel-hh.de>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle at amd.com>

V2: Adapt to different API of string buffer (Thomas Helland)

2017-09-26 18:25:20 +02:00

tests

Fix glcpp test expectations

2017-06-08 09:46:36 +02:00

.gitignore

glsl: move to compiler/

2016-01-26 16:08:33 +00:00

glcpp-lex.l

glcpp: Allow vertical tab and form feed characters in GLSL

2017-01-04 14:40:48 -08:00

glcpp-parse.y

glsl: Change the parser to use the string buffer

2017-09-26 18:25:00 +02:00

glcpp.c

glsl: reuse main extension table to appropriately restrict extensions

2016-07-23 13:48:04 -04:00

glcpp.h

glsl: Change the parser to use the string buffer

2017-09-26 18:25:00 +02:00

pp.c

glcpp: Use string_buffer for line continuation removal

2017-09-26 18:25:20 +02:00

README

glsl: move to compiler/

2016-01-26 16:08:33 +00:00

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