[HLSL] Rework semantic handling as attributes (#166796)
Previously, we had 2 level of attributes:
- HLSLUnparsedSemantic
- N attributes, one for each known system semantic.
The first was assigned during parsing, and carried no other meaning than
"there is a semantic token". It was then converted to one of the N
attributes later during Sema.
Those attributes also carried informations like "is indexable" or "is
index explicit".
This had a few issues:
- there was no difference between a semantic attribute applied to a
decl, and the effective semantic in the entrypoint use context.
- having the indexable bit was not useful.
- semantic constraints checks were split between .td files and sema.
Also, existing implementation had effective attributes attached to the
type decl or parameters, meaning struct decl reuse across entrypoints of
in a nested type was not supported, even if legal in HLSL.
This PR tried to simplifies semantic attribute by having 3 attributes:
- HLSLUnpasedSemantic
- HLSLParsedSemantic
- HLSLAppliedSemantic
Initial parsing emits an `HLSLUnparsedSemantic`. We simply say "here is
an HLSL semantic token", but we don't do any semantic check.
Then, Sema does initial validation and transforms an UnparseSemantic
into a ParsedSemantic. This validates a system semantic is known, or
that the associated type is valid (like uint3 for a ThreadIndex).
Then, once we parse an actual shader entrypoint, we can know how
semantics are used in a real context. This step emits a list of
AppliedSemantic. Those are the actual semantic in use for this specific
entrypoint.
Those attributes are attached to each entrypoint parameter, as a flat
list matching the semantic structure flattening HLSL defines. At this
stage of sema, index collision or other stage compabitility checkes are
carried.
This allows codegen to simply iterate over this list and emit the proper
DXIL or SPIR-V codegen.
