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?
There was a problem hiding this comment.
InitListExpr source ranges are basically the beginning of the first sub-expression to the end of the last. The locations could get a bit wonky, but for error reporting they should work well enough.
| ``` | ||
| 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.
Yea, that's what I was thinking. Basically the source location for each of the implicit access expressions points to the argument they are derived from.
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.
|
|
||
| # Initializer Lists | ||
|
|
||
| * Proposal: [NNNN](NNNN-initializer-lists.md) |
There was a problem hiding this comment.
small reminder to:
- add proposal number,
- rename file
- change status.
| HLSL's initializer lists assume a member-by-member flattened initialization | ||
| sequence. It is significantly different in behavior from C/C++ initializer | ||
| lists, but in a way that may not be apparent to users that they are depending on | ||
| the divergent behavior. This proposal suggests an approach to implementing |
There was a problem hiding this comment.
This line reads weird and could be stronger start with the forward looking modifier something like this:
This proposal offers a forward-looking approach to implementing HLSL's unique initializer behavior.
| ## Proposed solution | ||
|
|
||
| This solution is based on an assumption that we will adopt | ||
| [Proposal 0005 - Strict Initializer Lists](https://github.com/microsoft/hlsl-specs/blob/main/proposals/0005-strict-initializer-lists.md) |
There was a problem hiding this comment.
So the rich text looks fine but if you want to keep the column length looking more consistent in the raw text I saw justin does the below example on his proposals.
[TEXT][REF_NAME]
/// somewhere at the bottom of the file
[REF_NAME]: URL
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.