From 8e47a3802d4d74eb11620f147ef5b29b8e931d35 Mon Sep 17 00:00:00 2001 From: Tim Foley Date: Wed, 16 Jan 2019 11:50:14 -0800 Subject: 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. --- source/slang/diagnostics.cpp | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'source/slang/diagnostics.cpp') diff --git a/source/slang/diagnostics.cpp b/source/slang/diagnostics.cpp index 4cad7ce94..9a88c041d 100644 --- a/source/slang/diagnostics.cpp +++ b/source/slang/diagnostics.cpp @@ -61,6 +61,11 @@ void printDiagnosticArg(StringBuilder& sb, Type* type) sb << type->ToString(); } +void printDiagnosticArg(StringBuilder& sb, Val* val) +{ + sb << val->ToString(); +} + void printDiagnosticArg(StringBuilder& sb, TypeExp const& type) { sb << type.type->ToString(); -- cgit v1.2.3