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?
| typeof(g_int) g_typeof_int; // expected-error {{HLSL requires a type specifier for all declarations}} expected-error {{expected ';' after top level declarator}} expected-error {{unknown type name 'typeof'; did you mean 'typedef'?}} | ||
| typedef int (*fn_int)(int); // expected-error {{pointers are unsupported in HLSL}} | ||
| auto g_auto = 3; // expected-error {{'auto' is a reserved keyword in HLSL}} expected-error {{HLSL requires a type specifier for all declarations}} | ||
| auto g_auto = 3; // auto is now supported in HLSL via type deduction; no error expected |
There was a problem hiding this comment.
The purpose of HLSL 2015 is best-effort alignment with fxc compatibility for Intellisense API purposes only (non-compilation).
Technically, we should block this on HLSL 2015. I recognize that it's not a priority to maintain that use case at this point, but we still support this language version, and it should be easy to block based on that.
| // Test that 'auto' cannot be used to declare pointer types in HLSL. | ||
| // Pointers are unsupported in HLSL. | ||
|
|
||
| // CHECK: error: pointers are unsupported in HLSL |
There was a problem hiding this comment.
Shouldn't these be tested in a -verify test? For example in tools/clang/test/HLSL/cpp-errors.hlsl?
| // Test that 'auto' cannot be used to declare reference types in HLSL. | ||
| // References are unsupported in HLSL. | ||
|
|
||
| // CHECK: error: references are unsupported in HLSL |
3 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.