HLSL: Diverging preprocessor behavior

[TiemoJung]

Hi,

the preprocessor step seems to not handle constructs like this:

#define EXPAND(a)
struct A
{
float4 v EXPAND({1,2,3,4});
};

We use this technique to hide initializer lists that are used in shared code between HLSL and C++.

[johnkslang]

What did you want this to expand to?

The PP expands it to:

struct A
{
float4 v { 1, 2, 3, 4 };
};

Which looks illegal to me, so you should get some error out for that.

[TiemoJung]

It is expected to just do nothing (as EXPAND does nothing with the parameter), the problem is the parsing fails at the comma after the 1.

[johnkslang]

I see. I will look at fixing it.

[johnkslang]

The normative C++ specification for the preprocessor for GLSL says that commas separate arguments, unless they are nested in a pair of parentheses. Generally, the curly brace does not have meaning to the preprocessor.

Microsoft's DXC also sees the commas as argument separators, giving: error: too many arguments provided to function-like macro invocation

That is, the first argument, by any spec I can find, is {1. It seems pretty bizarre to have a preprocessor find and deal with match { ... } given how much the preprocessor is used to manipulate (turn on/off) such things. So, this is apparently a very specialized and ill-defined feature in FXC.

Since MS apparently agrees, given the behavior of DXC, perhaps you want a different approach?

Or, would you still want glslang to match FXC behavior for HLSL instead of matching DXC?

Or, do you think this is a bug in DXC?

@antiagainst might be interested in this as well.

[TiemoJung]

We would like to have this to have parity with FXC.
An alternative would be to have variadic macros.

[johnkslang]

I'll look into it.

Out of curiosity, what C++ compiler is accepting this? It would also seem to be out of spec.

[TiemoJung]

Basically the same macro is for HLSL a single argument macro (as fxc does not support var arg macros, but it accepts this malformed form somehow) and for normal c/c++ its a var arg macro.

[antiagainst]

Interesting! Thanks @johnkslang!

@TiemoJung: You said that the above macro is used for sharing code between HLSL and C++. But I'm wondering whether GCC/Clang accepts the above syntax at all: https://stackoverflow.com/questions/30372148/passing-an-initialization-list-to-a-macro

Yes, FXC supports it, but agreed to @johnkslang: this seems a pretty ill-defined feature. From my understanding, the long-term goal of HLSL is to be more C++-like, with one of its goal to foster code sharing between HLSL and C++. Thus DXC is based on LLVM/Clang. And we already have divergent behavior between DXC and FXC for macro to improve the sharability between HLSL and C++: microsoft/DirectXShaderCompiler#1005.

[johnkslang]

If curly braces are not recognized to protect comma as argument separators, then the comma becomes a separator. That means, EXPAND({1, 2, 3, 4}) has 4 arguments instead of 1: {1, 2, 3, 4}, hence the need for either variadic arguments or recognizing {...} as a comma container. If DXC has one or the other, it is okay.