Implement auto for C++11-style type deduction

[llvm-beanz]

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 ResourceDescriptorHeap and SamplerDescriptorHeap.

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.

[bob80905]

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?

[llvm-beanz]

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 groupshared argument feature in 202x, where we exposed it in earlier versions with a warning. The subtle thing that makes this different from say the change in #8453, is that this isn't actually a change to the parsing grammar, it's an additive change to the semantics. The additive change doesn't break anything in existing because we always treated auto as a reserved word.

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]

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?

[llvm-beanz]

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:

This is still missing special handling for non-deducible special HLSL types. The main one that comes to mind is the type of the ResourceDescriptorHeap and SamplerDescriptorHeap

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 so I thought it best to split the two up.

[hekota]

LGTM!