[PATCH vkd3d 1/5] vkd3d-shader: Partially implement #define.

[Zebediah Figura (she/her)]

On 1/5/21 12:02 PM, Henri Verbeet wrote:
> On Tue, 5 Jan 2021 at 18:22, Zebediah Figura (she/her)
> <zfigura at codeweavers.com> wrote:
>>
>> On 1/5/21 11:12 AM, Henri Verbeet wrote:
>>> On Tue, 5 Jan 2021 at 17:17, Zebediah Figura <zfigura at codeweavers.com> wrote:
>>>> @@ -41,6 +47,8 @@ struct preproc_ctx
>>>>      struct vkd3d_string_buffer buffer;
>>>>      struct vkd3d_shader_location location;
>>>>
>>>> +    struct list macros;
>>>> +
>>> Does that need to be a list? For the purposes of this series, it seems
>>> an array would work at least as well.
>>>
>> It eases removal via #undef. There's also a couple places that
>> store pointers to the macro (I think they're not in this series, but
>> rather relate to expansion) which would complicate using a flat array at
>> least.
> 
> Unless we care about the order, removal would essentially be
> "macros[idx] = macros[--macro_count];"

True; I forgot about that.

> Storing pointers to macros would indeed be an issue, although I'd
> expect that to be an issue regardless of how macros are stored, unless
> you also e.g. reference count them. Either way, if it's needed for
> later patches that's fine.
> 

That is true. Of course, using an array makes it worse, because now
you're potentially affecting macros other than the one that's being
deleted while expanded.

Incidentally, the following shader:

#define FUNC(a,b) a ## b
FUNC(a,
#undef FUNC
b)

yields, with native d3dcompiler_47, the output "FUNC" and an error "not
enough actual parameters for macro 'FUNC'".

I don't think it'd be very hard to fix up the code to make sure a macro
in use can't be moved, but on the other hand it strikes me as
unnecessarily fragile (wrt later reading or modification).

I also don't know how much of a performance concern this actually is.