fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2026-05-19 20:08:06 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 4
mesa/src/compiler/glsl/glcpp/tests/124-preprocessing-numbers.c.expected

38 lines
190 B
Text
Raw Normal View History

glsl/glcpp: Fix glcpp to properly lex entire "preprocessing numbers" The preprocessor defines a notions of a "preprocessing number" that starts with either a digit or a decimal point, and continues with zero or more of digits, decimal points, identifier characters, or the sign symbols, ('-' and '+'). Prior to this change, preprocessing numbers were lexed as some combination of OTHER and IDENTIFIER tokens. This had the problem of causing undesired macro expansion in some cases. We add tests to ensure that the undesired macro expansion does not happen in cases such as: #define e +1 #define xyz -2 int n = 1e; int p = 1xyz; In either case these macro definitions have no effect after this change, so that the numeric literals, (whether valid or not), will be passed on as-is from the preprocessor to the compiler proper. This fixes the following Khronos GLES3 CTS tests: preprocessor.basic.correct_phases_vertex preprocessor.basic.correct_phases_fragment v2. Thanks to Anuj Phogat for improving the original regular expression, (which accepted a '+' or '-', where these are only allowed after one of [eEpP]. I also expanded the test to exercise this. v3. Also fixed regular expression to require at least one digit at the beginning (after an optional period). Otherwise, a string such as ".xyz" was getting sucked up as a preprocessing number, (where obviously this should be a field access). Again, I expanded the test to exercise this. Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2014-06-12 14:56:47 -07:00
1e
1OK
123e+OK
.23E+OK
1.3e-OK
12.E-OK
123p+OK
.23P+OK
1.3p-OK
12.P-OK
123..OK
.23.OK.OK
123ef+GO
.23E3-GO
1.3e--GO
12.E-&GO
123p+OK+GO
.23P+OK;GO
1.3p-OK-GO
12.P-OK&GO
Reference in a new issue Copy permalink