[PATCH vkd3d 1/3] vkd3d-shader/hlsl: Set the name for anonymous structures at creation time.

[Zebediah Figura (she/her)]

On 10/5/21 03:21, Matteo Bruni wrote:
> On Mon, Oct 4, 2021 at 3:52 AM Zebediah Figura <zfigura at codeweavers.com> wrote:
>>
>> Signed-off-by: Zebediah Figura <zfigura at codeweavers.com>
>> ---
>> This series is kind of an RFC, though, because I'm not actually sure we want to
>> do this. The obvious benefit is that we get rid of a lot of common boilerplate
>> that's otherwise pretty hard to sidestep—as shown by the diffstat in patch 3. On
>> the other hand, we might want to do something like GCC's "x <aka y>", in which
>> case this would be a step in the wrong direction (and a pretty impactful step at
>> that.)
> 
> This is generally fine to me, although I don't think I see much of an
> improvement from this going forward. Basically all the cases that are
> simplified in patch 3 are error messages (unsurprisingly); simplifying
> the code for those is nice and good but probably not too big of a
> deal. It would be more significant if we were to add many more errors
> down the line or if the same kind of boilerplate started to be
> required in some other places, possibly far from error paths. Maybe
> that's actually the case?

Nothing that occurs to me at the moment, no.

On the other hand I wouldn't be surprised if we add a lot more errors 
going forward...

> I guess that kind of "x (aka y)" notes in error messages would be nice
> to have, although probably not critical. I don't know that the changes
> made by this patch series would matter a whole lot in that regard
> though? It shouldn't make a difference for named types and those are
> often the most interesting ones to "unravel" (I'm thinking of the
> usual typedef case here).

I wasn't really planning on implementing it any time soon, but I don't 
want to step in the wrong direction if it's desirable at all.

The idea is that if you want "x (aka y)" you'd probably add that 
capability to hlsl_type_to_string() [or introduce a similar function 
while keeping hlsl_type_to_string() around].

I guess that name too could always be stored in the type object...

Or we could forgo this series but have special format modifiers for 
various things. That takes work too though. Probably best just to leave 
things alone for now.

>> (This series also has us taking a bit more memory, but it's not a lot. We
>> already allocate names for all numeric types, since they aren't keywords.)
> 
> Yeah, I'm not particularly concerned by that either.
>