Implement auto for C++11-style type deduction#8452
Conversation
This is a partial proof of concept of C++11-stlye type deduction being added to HLSL under the 202x language mode. This is still missing special handling for non-deducable special HLSL types. The main one that comes to mind is the type of the `ResourceDescriptorHeap` and `SamplerDescriptorHeap`.
bob80905
left a comment
bob80905
left a comment
There was a problem hiding this comment.
My only concern is that this seems to add auto for all language modes, only emitting a warning for < 202x, like C++. But the description suggests that auto is only being added for >= 202x.
Should we, unlike the C++ scenario, emit a hard error for auto < 202x?
We followed the same pattern for the The benefit of adding this in older language modes is that users can start using it right away without needing to deal with any of the other behavioral changes in 202x, and we can start using it right away in library code and to make library code more readable without forcing users to move to 202x in order to use the libraries. |
tex3d
left a comment
tex3d
left a comment
There was a problem hiding this comment.
Shouldn't we test auto with some HLSL-specific object types, plus make sure you can't use it to capture the hidden intermediate resource/sampler type from ResourceDescriptorHeap/SamplerDescriptorHeap used for dynamic resources?
I explicitly called this out in the description:
I believe this change stands on its own and is fine to go in with the expectation that we'll prevent deducing some objects in a follow-up change. I think the correct design for marking some built-in types as non-deducible is likely a bigger change than just enabling |
| auto sum = a + a; | ||
| // expected-warning@+1 {{'auto' type specifier is a HLSL 202x extension}} | ||
| auto product = b * b; | ||
|
|
There was a problem hiding this comment.
Suggestion: add test for auto from return value of an intricsic call
There was a problem hiding this comment.
Good call! Added a few.
| // CHECK-LABEL: define void @main() | ||
| // DXIL: define void @main() |
There was a problem hiding this comment.
Should this be -verify test with no expected diagnostics?
There was a problem hiding this comment.
I think it's probably worth testing the alloca variable types to make sure the correct types are generated in codegen. I've updated the test.
../tools/clang/test/HLSLFileCheckLit/hlsl/auto/auto-template.hlsl ../tools/clang/test/HLSLFileCheckLit/hlsl/auto/auto-variable-deduction.h lsl
4 participants
Partial implementation of C++11-stlye type deduction added to HLSL under the 202x language mode.
This is still missing special handling for non-deducible special HLSL types. The main one that comes to mind is the type of the
ResourceDescriptorHeapandSamplerDescriptorHeap.I think this PR can stand on its own because using it to infer those special types won't technically break anything it just might expose some bits and pieces of the implementation that we don't want.