[PATCH vkd3d 3/5] vkd3d-shader: Print offending values for more error messages.

[Matteo Bruni]

On Fri, Mar 5, 2021 at 3:31 AM Zebediah Figura (she/her)
<zfigura at codeweavers.com> wrote:
>
> On 3/4/21 3:54 AM, Matteo Bruni wrote:
> > On Tue, Mar 2, 2021 at 10:35 PM Zebediah Figura <zfigura at codeweavers.com> wrote:
> >>
> >> Signed-off-by: Zebediah Figura <zfigura at codeweavers.com>
> >> ---
> >>  libs/vkd3d-shader/hlsl.y | 97 ++++++++++++++++++++++++++++++----------
> >>  1 file changed, 74 insertions(+), 23 deletions(-)
> >
> > I'm hijacking this one just to refer to the existing code.
> >
> >> @@ -1438,7 +1459,8 @@ static struct list *declare_vars(struct hlsl_ctx *ctx, struct hlsl_type *basic_t
> >>                  if (size < type->dimx * type->dimy)
> >>                  {
> >>                      hlsl_error(ctx, v->loc, VKD3D_SHADER_ERROR_HLSL_WRONG_PARAMETER_COUNT,
> >> -                            "Wrong number of parameters in numeric initializer.");
> >> +                            "Expected %u components in numeric initializer, but got %u.",
> >> +                            type->dimx * type->dimy, size);
> >>                      free_parse_initializer(&v->initializer);
> >>                      vkd3d_free(v);
> >>                      continue;
> >
> > It would be interesting to know (or probably, remember) why this is
> > complaining if the initializer is smaller than required but not if
> > it's larger. Native _43 seems to report an error in both cases, maybe
> > older compilers didn't? Or maybe it's just wrong...
> >
>
> I believe you're half right, which unfortunately isn't enough. I think
> the point of this is to catch
>
> float4 a;
> float3 b = {a.x, a.y};
>
> but it also catches
>
> float4 a;
> float4 b = a.xy;
>
> and may in fact have been written with solely the latter in mind, in
> which case truncation is not an error. The tricky thing is that
>
> float4 a;
> float3 b = {a.x, a.y, a.z, a.w};
>
> is invalid (native says "initializer does not match type"), and so is
>
> float4 a;
> float3 b = {a.xyzw};
>
> but
>
> float4 a;
> float3 b = a.xyzw;
>
> only yields an "implicit truncation" warning.
>
> We get the warning and type checking from the add_assignment() call, for
> what it's worth, so we really only need to check when there are explicit
> braces.

This sounds somewhat familiar now. I think you're correct that this
was added only for the second case and tightening the error check is
the way to go.