glcpp mingw failing in the following way:
```
49/56 mesa:compiler+glcpp / glcpp test (unix) FAIL 3.39s exit status 1
50/56 mesa:compiler+glcpp / glcpp test (oldmac) FAIL 3.41s exit status 1
51/56 mesa:compiler+glcpp / glcpp test (bizarro) FAIL 3.42s exit status 1
52/56 mesa:compiler+glcpp / glcpp test (windows) FAIL 3.45s exit status 1
```
The test failed because on mingw, the stderr will comes after stdout,
but all the expect files, the stderr is coming first,
so we flush(stderr) first to makesure stderr out before stdout
The failing example:
039-func-arg-obj-macro-with-comma: FAIL
---
+++
@@ -1,3 +1,5 @@
+0:12(21): preprocessor error: Error: macro foo invoked with 2 arguments (expected 1)
+
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26778>
valgrind flagged members of gl_ctx->Extensions being used uninitialized:
==23417== Conditional jump or move depends on uninitialised value(s)
==23417== at 0x112642: _glcpp_parser_handle_version_declaration.part.0 (glcpp-parse.y:2493)
==23417== by 0x11A515: glcpp_lex_update_state_per_token (glcpp-lex.l:132)
==23417== by 0x11A515: glcpp_lex (glcpp-lex.l:547)
==23417== by 0x114D46: glcpp_parser_lex (glcpp-parse.y:2302)
==23417== by 0x114D46: glcpp_parser_parse (glcpp-parse.c:1871)
==23417== by 0x11ADC6: glcpp_preprocess (pp.c:238)
==23417== by 0x111384: main (glcpp.c:174)
==23417== Uninitialised value was created by a stack allocation
==23417== at 0x111295: main (glcpp.c:136)
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9528>
- remove mtypes.h from most header files
- add main/menums.h for often used definitions
- remove main/core.h
v2: fix radv build
Reviewed-by: Brian Paul <brianp@vmware.com>
Previously we were only restricting based on ES/non-ES-ness and whether
the overall enable bit had been flipped on. However we have been adding
more fine-grained restrictions, such as based on compat profiles, as
well as specific ES versions. Most of the time this doesn't matter, but
it can create awkward situations and duplication of logic.
Here we separate the main extension table into a separate object file,
linked to the glsl compiler, which makes use of it with a custom
function which takes the ES-ness of the shader into account (thus
allowing desktop shaders to properly use ES extensions that would
otherwise have been disallowed.) We can also now use this logic to
generate #define's for all supported extensions automatically, removing
the duplicate (and often inaccurate) list in glcpp.
The effect of this change should be nil in most cases. However in some
situations, extensions like GL_ARB_gpu_shader5 which were formerly
available in compat contexts on the GLSL side of things will now become
inaccessible.
This regresses two ES CTS tests:
ES3-CTS.shaders.shader_integer_mix.define
ES31-CTS.shader_integer_mix.define
however that is due to them using #version 100 instead of 300 es. As the
extension is only defined for ES3, I believe this is the correct
behavior.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v2)
v2 -> v3: integrate glcpp defines into the same mechanism
