Hi,
Il 06/05/22 15:43, Francisco Casas ha scritto:
Here we are in the context of a struct field, where is seems that any kind of unbounded array is forbidden, isn't it? I mean, it should be an hlsl_error(), not an hlsl_fixme(): this program fails to compile with native:
struct ss { Texture2D x[]; };
float4 main() : sv_target { struct ss arr;
return 0.0; }
As Zebediah pointed out in her reviews of my previous patches, in ps_5_1 and vs_5_1, arrays of textures are processed as a different datatype, and they are allowed to be implicit, and even be struct members. They are called "unbounded resource arrays".
For instance, your example actually compiles with ps_5_1.
So it was decided to drop those variables for now.
Ah yes, you're right, it was already discussed. Sorry, I keep getting confused by all these language inconsistencies.
Still, you can merge the other two branches, I'd say: unless I am missing something, it seems that the only case in which an implicit-sized array is allowed in a struct is when the shader model is
= 5.1 and we're dealing with an unbounded resource array (because SM = 5.1 really treats it as a single object). All the other cases can
live within the same branch and error message.
Once this is taken into account, it seems that any kind of implicit array is just forbidden inside a struct definition, so you can avoid different cases depending on the underlying type: if you see _COUNT_IMPLICIT inside gen_struct_field() you just hlsl_error() out (just like you do for typedefs, for instance). This would also agree with the native d3dcompiler's error message: "array dimensions of struct/class members must be explicit", though that's not necessarily a strong argument. Or an argument at all. Just a funny coincidence.
Well, as I mentioned that's not totally true in ps_5_1.
I could check that the profile is >= 5.1 in the conditionals.
This would make sense to me.
I see. I have been pushing for hlsl_type_component_count() to return 1 with objects, so that initializers work correctly on structs that have object members, like in:
Texture2D tex;
struct foo { float2 aa; Texture2D bb[2]; float4 cc; };
float4 main() : sv_target { struct foo q = {10, 20, tex, tex, 30, 40, 50, 60};
return q.cc;}
This indeed seems necessary for the condition '(size == 0)' to not be redundant.
Instead of removing it, I suggest considering first a patch so that hlsl_type_component_count() returns 1 for objects. I will get to work on it.
This also seems to make sense.
Interestingly this shader does not compile with SM5.1, I suppose that's another artifact of treating arrays of resources as single objects themselves. But as Zeb suggests, this probably has to be dealt with at parsing time, by generating an entirely different object type.
Thanks, Giovanni.