Make "tested" and "statically declared" preprocessor symbols visible to the caller

[St0fF-NPL-ToM]

Some kinds of uber-shader editors have means to enable or disable specific named defines via Checkboxes. For that it would be good to be able to access all used named defines after parsing a shader.

Definition "static named define":

#define SOME_NAME

Definition "checked named define":

#ifdef ANOTHER_NAME
  [...shader code...]
#elif not defined A_THIRD_NAME
  [...more shader code...]
#endif

The simplest solution to this would be to add two public sets to TIntermediate:

public:
    std::unordered_set< std::string > checkedDefines, staticDefines;

and inserting the required code to add symbols to those sets everywhere necessary in the preprocessor code (Pp.cpp - it's only very few lines). Though this approach looks more like a hack to me, thus it should be discussed in depth to find a maybe more sophisticated solution.

About the insertions within Pp.cpp: they should actively check if the Pp has already reached user code, thus it is not within a manually given preamble. The thought behind this is, that "-D" compiler flags could be prepared as a preamble of a bunch of #define symbol-lines.

[St0fF-NPL-ToM]

In my pull request #1341 I tried to implement it more object oriented and with proper data encapsulation. I.e. make those sets internal, using the pool-allocated TString. And finally add accessor functions to insert the found "named defines" into a given std::unordered_set< std::string >, as an editor would most likely want to cumulate all named defines from all shader stages.

[johnkslang]

I see.

Let's first separate adding new functionality from fixing build issues. (I suspect this was accidental.)

[St0fF-NPL-ToM]

Ok, to start the discussion:
I think "statically declared defines" actually do not need further code inside the Pp, as we could simply iterate over the macro defs and use all those without parameters and without a body. So the question there would be: is the TPpContext visible and accessible from TIntermediate?

About the "tested defines" I agree, as it's a feature, it should be guarded by a feature request. Questions are:

• where should the guard be put, what kind of guard to use
• would it suffice to simply store atom indices (accessibility of TPpContext from TIntermediate) in a set or even a vector

[St0fF-NPL-ToM]

I'm gonna bump this now after a week without any discussion, with my current thoughts.

I needed and implemented this functionality with a certain use-case in mind (see 1st post). This was made to work purely inside the C++ interface, thus no support in the executable glslangvalidator is needed.

The implementation for gathering necessary data was inserted into already fully tested and functional code (Pp.cpp) at the only locations where it is useful. A special "code execution feature-guard" would need deep internal changes, at least as far as I analyzed the code. Which stands in no relation to the few allocations and string copy operations that may happen due to execution of the code itself.

Therefore I no more believe in the necessity of "feature guarding", nor in providing extra tests. Feature-guards would most likely add further parameters to certain function calls, which may break existing other-party code. Tests would only take me ages to understand the testing enviroment, but give no benefit other than showing that the preprocessor is broken - which I guess is already covered by other tests.

So I'm going to wait for further discussion / comments for a few days and then bring up a pull request (I'll give my best to make it conformant to code formatting policies), again, given my arguments are valid.

[St0fF-NPL-ToM]

See pull request #1849