HLSL Initializer List Support #75
Conversation
This PR adds a proposal for HLSL initializer list support to align Clang with DXC's behavior while providing a path forward to a better language implementation in the future.
proposals/xxxx-initializer-lists.md
Outdated
|
|
||
| ```hlsl | ||
| float4 F = 1.0.xxxx; | ||
| struct A { |
There was a problem hiding this comment.
Consider renaming struct A to avoid potential conflict with the earlier declaration viz.,
struct A {
int a;
double b;
};
specifically for the variable declaration A a = {F.x, F.y, F.z, F.w}; later in the document.
| Given the differences in the language described above it is likely too | ||
| significant of a change to make Clang follow C/C++ behavior without a transition | ||
| period. Since Clang and DXC will have different underlying representations for |
There was a problem hiding this comment.
| Given the differences in the language described above it is likely too | |
| significant of a change to make Clang follow C/C++ behavior without a transition | |
| period. Since Clang and DXC will have different underlying representations for | |
| Given the differences in the languages as described above it is likely changes | |
| needed to make Clang follow C/C++ behavior would be significant thereby requiring | |
| a transition period. Since Clang and DXC will have different underlying representations for |
| compatibility with existing HLSL, this proposal suggests that Clang parse HLSL | ||
| initialization syntax into valid C++ initializer list ASTs. | ||
|
|
||
| This would mean that given an example like: |
There was a problem hiding this comment.
| This would mean that given an example like: | |
| This would mean that given an HLSL example code such as: |
| ImplicitCastExpr float->half | ||
| ExtVectorElementExpr .w | ||
| DeclRefExpr F | ||
| ``` |
There was a problem hiding this comment.
Rename F as f following changes in commit 6902340
|
|
||
| ```hlsl | ||
| B b3 = {{{1, 2}, {3, 4}}, 5}; | ||
| A a = {F.x, F.y, F.z, F.w}; |
There was a problem hiding this comment.
Should F be renamed as f following changes in commit 6902340?
Given
struct A {
int a;
double b;
};
is this initilization correct? Should it be A a = {f.x, f.y}?
| ``` | ||
| InitListExpr | ||
| InitListExpr | ||
| InitListExpr |
There was a problem hiding this comment.
I wonder how source range would be set for these expressions. Would we just point from the first element to the last element that the expression corresponds to, even though it will cross weird grouping boundaries?
| ``` | ||
| InitListExpr | ||
| ImplicitCastExpr float->int | ||
| ExtVectorElementExpr .x |
There was a problem hiding this comment.
What would we set for source locations for expressions like this? Just point to f for all of them?
There was a problem hiding this comment.
This looks good, though as Tex points out I think there are a lot of questions that this opens up about the debug info story. I suspect we'll have to just accept that source locations for these expressions will need to be very limited, since the AST doesn't actually match the source.
This PR adds a proposal for HLSL initializer list support to align Clang with DXC's behavior while providing a path forward to a better language implementation in the future.