[Mesa-dev] [PATCH 0/9] glsl: cleanup and fix handling of unnamed struct types

[Nicolai Hähnle]

On 15.05.2017 16:57, Erik Faye-Lund wrote:
> On Mon, May 15, 2017 at 11:27 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>> Hi all,
>>
>> This series aims to simplify how we handle unnamed struct types and fix some
>> bugs on the way. Some of the patches should be uncontroversial, and all of
>> them align with my understanding of the GLSL spec, but the spec isn't
>> exactly explicit, so...
>>
>> At a high level, the series changes two things:
>>
>> 1) Unnamed structs can never match named structs during linking.
>>
>> 2) Unnamed structs are considered the same type if they have the same
>> content. They will literally use the same glsl_type instance.
>>
>> The second point causes a deviation from the behavior of C/C++, in that the
>> following code snippet now compiles (and does the reasonable thing):
>>
>>   struct { float a; } s1;
>>   struct { float a; } s2;
>>
>>   s2 = s1;
>>
>> The justification is basically that the GLSL spec says (when it comes to
>> linking, in Section 4.2) that
>>
>>    "Structures must have the same name, sequence of type names, and
>>     type definitions, and member names to be considered the same type."
>>
>> And since people generally seem to read that as mandating that globals of
>> unnamed struct types should match if they're structurally the same, and the
>> GLSL spec otherwise says nothing (as far as I can tell) about when struct
>> types are equal, the cleanest thing is to just say that _in general_ (not
>> just for linking) struct types are the same if and only if they have the
>> same name and the same fields; where "same name" can mean that they both
>> have no name.
>
> It might also be reasonable to say that having the same name requires
> having a name in the first place. But I'm not sure if such an
> interpretation is useful.

I agree. But it seems the ship has sailed on that one at least when it 
comes to cross-stage validation.


> So, I think it would be useful to look at what other implementations
> do. From a quick test, it seems like both glslangValidator, the Apple
> GLSL compiler (as reported by OpenGL Shader Builder, on Intel HD
> Graphics 5000) as well as the NVIDIA Windows driver allows your
> example (and all of them forbids it if I add another member to one of
> them, or rename the member). Those are the only implementations I have
> at hand right now, but it seems to me like this behavior is at least
> not too controversial.

Thank you for testing, that's indeed good to know!

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.