Improve handling of {} initializer list expressions (#778)

Fixes #775

It was reported (in #775) that Slang doesn't handle initializer-list syntax when initializing matrix variables. When starting on a fix for that it became apparent that the time was right to fix two broad issues in the compiler's current handling of `{}`-enclosed initializer lists.

The first issue was that the front-end checking of initializer lists wasn't handling the C-style behavior where an initializer list can either contain nested `{}`-enclosed lists for sub-arrays/-structures, or directly contain "leaf" values for initializing those aggregates. For example, the following two variable declarations ought to be equivalent:

```hlsl
int4 a[] = { {1, 2, 3, 4}, {5, 6, 7, 8} };
int4 b[] = {  1, 2, 3, 4,   5, 6, 7, 8 };
```

Getting this distinction right is important because we want to support initializing a matrix either from a list of vectors for its rows, or a list of scalars for its elements (in row-major order).

The front-end semantic checking logic for initializer lists was revamped so that it conceptually tries to "read" an expression of a desired type from the initializer list, and decides at each step whether to consume a single expression by coercing it to the desired type, or to recursively read multiple sub-values to construct the type as an aggregate. The logic for deciding between direct vs aggregate initialization could potentially use some tweaking, but luckily it should always handle the case where users introduce explicit `{}`-enclosed sub-lists to make their intention clear, so that existing Slang code should continue to work as before.

The second issue was that initializers without the expected number of elements weren't implemented in code generation, so they would lead to internal compiler errors. This change revamps the codegen logic for initializer lists so that it can synthesize default values for fields/elements that were left out during initialization. This includes an attempt to support default initialization of `struct` fields based on explicitly written initialization expressions.

2 files changed, 36 insertions, 0 deletions

diff --git a/tests/bugs/gh-775.slang b/tests/bugs/gh-775.slang
new file mode 100644
index 000000000..f8125d7d4
--- /dev/null
+++ b/tests/bugs/gh-775.slang
@@ -0,0 +1,32 @@
+// gh-775.slang
+//TEST(compute):COMPARE_COMPUTE:
+
+int test(int inVal)
+{
+    float4x4 identity = {
+        1, 0, 0, 0,
+        0, 1, 0, 0,
+        0, 0, 1, 0,
+        0, 0, 0, 1
+    };
+
+    float4 v = float4(inVal, inVal+1, inVal+2, inVal+3);
+
+    v = mul(identity, v);
+
+    return int(dot(v, float4(1, 16, 256, 4096)));
+}
+
+//TEST_INPUT:ubuffer(data=[9 9 9 9], stride=4):dxbinding(0),glbinding(0),out
+RWStructuredBuffer<int> outputBuffer : register(u0);
+
+[numthreads(4, 1, 1)]
+void computeMain(uint3 dispatchThreadID : SV_DispatchThreadID)
+{
+	uint tid = dispatchThreadID.x;
+
+	int inVal = int(tid);
+	int outVal = test(inVal);
+
+	outputBuffer[tid] = outVal;
+}
\ No newline at end of file
diff --git a/tests/bugs/gh-775.slang.expected.txt b/tests/bugs/gh-775.slang.expected.txt
new file mode 100644
index 000000000..611a87ad6
--- /dev/null
+++ b/tests/bugs/gh-775.slang.expected.txt
@@ -0,0 +1,4 @@
+3210
+4321
+5432
+6543