[PATCH] D127802: [HLSL] Support HLSL vector initializers

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.


================
Comment at: clang/test/SemaHLSL/BuiltIns/vector-constructors-erros.hlsl:8
+void entry() {
+  float2 LilVec = float2(1.0, 2.0);
+  float2 BrokenVec = float2(1.0, 2.0, 3.0); // expected-error{{excess elements in vector initializer}}
----------------
beanz wrote:
> aaron.ballman wrote:
> > beanz wrote:
> > > python3kgae wrote:
> > > > Could we have test case for array/struct when initialize vector?
> > > > Like
> > > > float a[2] = {1.2, 3.2};
> > > > float4 arrayVec = float4(a, 1.0, 2.0);
> > > This change does not support all of HLSL's odd initialization features. It only supports initializing vectors from scalars and vectors.
> > I'm surprised to see `float(1.0, 2.0)` work -- that's not list initialization, it's using round parens instead of curly braces so I'm pretty sure that's a function-style cast/constructor. Is that intentional?
> Yea, it's a bit gross. HLSL supports function cast for vector construction, by converting the parameters inside to an initialization list.
> 
> HLSL also has some super odd initialization list behaviors that I'm trying to figure out a reasonable way to handle (while also hoping to remove them from the language).
Ahhhh okay, I was confused -- I thought the goal was to allow direct init list initialization. Thanks for clarifying.


================
Comment at: clang/test/SemaHLSL/BuiltIns/vector-constructors-erros.hlsl:12
+  float3 BrokenNormie = float3(3.0, 4.0); // expected-error{{too few elements in vector initialization (expected 3 elements, have 2)}}
+  float3 OverwhemledNormie = float3(3.0, 4.0, 5.0, 6.0); // expected-error{{excess elements in vector initializer}}
+}
----------------
How do these examples behave:
```
float f = 1.0f, g = 2.0f;
float2 foo0 = float2(f, g); // Non-literal

int i = 1, j = 2;
float2 foo1 = float2(1, 2); // Integer literals
float2 foo2 = float2(i, j); // Integer non-literal

struct S { float f; } s;
float2 foo3 = float2(s, s); // No potential type conversion possible
float2 foo4 = float2(s.f, s.f); // Should work though?

// and for good measure
struct T {
  operator float() const;
} t;
float2 foo5 = float2(t, t); // Should work though?

typedef float2 second_level_of_typedefs;
second_level_of_typedefs foo6 = float2(1.0f, 2.0f); // Should work though?
float2 foo7 = second_level_of_typedefs(1.0f, 2.0f); // Should work though?
```


================
Comment at: clang/test/SemaHLSL/BuiltIns/vector-constructors.hlsl:1
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -x hlsl -ast-dump -o - %s | FileCheck %s 
+
----------------
I don't feel strongly, but `-ast-dump` tests often go under `clang/test/AST` because they're not really testing semantics so much as what information we've dumped out to represent those semantics.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127802/new/

https://reviews.llvm.org/D127802