[Semantics] Determine design to map effective semantic to each parameter field

[Keenuts]

Current semantic implementation does not support struct reuse across inputs if nested.
Reason is we have a 1:1 mapping for each semantic attribute to a declaration, ignoring the actual parents of this declaration:

struct S0 {
    int s0_f0 : SEMANTIC_0;
}

struct S1 {
    int s1_f0 : SEMANTIC_1;
    S0  s1_f1: SEMANTIC_2;
}

void main(S0 main0, S1 main1) { }

In this case, the main function will have several semantic attributes:

Semantic0Attr -> s0_f0 decl.
Semantic1Attr -> s1_f0 decl.
Semantic2Attr -> s0_f0 decl.

This causes an issue as there is no clear way to differentiate which attribute applies to main1.s1_f1.s0_f0 or main0.s0.f0.

Multiple solutions are available, but needs to be explored so we can move forward:

• consider a 1:1 flat mapping which maps the unwrapped struct hierarchy. Here the order would carry semantic, meaning Semantic2Attr would only belong to the 3rd unwrapped field, so main1.s1_f1.s0_f0.
• consider storing the entier path in the attribute: instead of storing the last level decl, store each decl leading to this, so here main1 -> s1_f1 -> s0_f0. This would allow disambiguation while ignoring the attribute ordering on the function decl.

[Keenuts]

One solution I'd suggest is to move to a solution with 3 attributes:

def HLSLUnparsedSemantic : HLSLAnnotationAttr {
  let Spellings = [];
  let Args = [DefaultIntArgument<"Index", 0>,
              DefaultBoolArgument<"ExplicitIndex", 0>];
  let Subjects = SubjectList<[ParmVar, Field, Function]>;
  let LangOpts = [HLSL];
  let Documentation = [InternalOnly];
}

class HLSLSemanticBaseAttr : HLSLAnnotationAttr {
  int SemanticIndex = 0;

  let Spellings = [];
  let Subjects = SubjectList<[ParmVar, Field, Function]>;
  let LangOpts = [HLSL];
}

def HLSLParsedSemantic : HLSLSemanticBaseAttr {
  let Spellings = [];
  let Subjects = SubjectList<[ParmVar, Field, Function]>;
  let LangOpts = [HLSL];
  let Documentation = [InternalOnly];

  let Args = [StringArgument<"SemanticName">, IntArgument<"SemanticIndex">];
}

def HLSLAppliedSemantic : HLSLSemanticBaseAttr {
  let Spellings = [];
  let Subjects = SubjectList<[ParmVar, Field, Function]>;
  let LangOpts = [HLSL];
  let Documentation = [InternalOnly];

  let Args = [StringArgument<"SemanticName">, IntArgument<"SemanticIndex">];
}

• HLSLUnparsedSemantic: this is what the lexer/parser outputs. It has no understanding of the context, simply marks the semantic presence in the initial AST. Anything that looks like a semantic with valid syntax (no emojis, etc) is transformed into this attribute.

• HLSLParsedSemantic: this is during early sema, when we are parsing the initial declarations but have no usage context yet. At this state, we can do early validation like : "is there an explicit index to a semantic SV_GroupThreadID", or "is the type associated with SV_GroupThreadID a uint/uint2/uint3/uint4?"

Those are attached to the AST in place of the declaration. Meaning they can be found on Fields, Function, or ParmVar.

• HLSLAppliedSemantic: generated during late sema, this represents the effective semantic with proper indices deduction etc. This step validate the stage/semantic compatibility, as well as indices legality and other constructions.
  Those can be found attached in sequence to a ParmVar, the order matching the order of the flattened struct layout.

Here is an AST for the following HLSL:

struct S0 {
  uint f0 : A;
  uint f1 : C;
};

struct S1 {
  S0 f0;
  S0 f1 : B;
};

[numthreads(1, 1, 1)]
void main(S1 p0 : D, S1 p1) {
}

|-CXXRecordDecl 0x55edfa7e0cf8 </tmp/a.hlsl:4:1, line:7:1> line:4:8 referenced struct S0 definition
| |-DefinitionData pass_in_registers aggregate standard_layout trivially_copyable pod trivial literal
| | |-DefaultConstructor exists trivial needs_implicit
| | |-CopyConstructor simple trivial has_const_param needs_implicit implicit_has_const_param
| | |-MoveConstructor exists simple trivial needs_implicit
| | |-CopyAssignment simple trivial has_const_param needs_implicit implicit_has_const_param
| | |-MoveAssignment exists simple trivial needs_implicit
| | `-Destructor simple irrelevant trivial needs_implicit
| |-PackedAttr 0x55edfa7e0da0 <<invalid sloc>> Implicit
| |-CXXRecordDecl 0x55edfa7e0e60 <col:1, col:8> col:8 implicit struct S0
| |-FieldDecl 0x55edfa7e0f60 <line:5:3, col:8> col:8 f0 'uint':'unsigned int'
| | `-HLSLParsedSemanticAttr 0x55edfa7e0fb0 <col:13> "A" 0
| `-FieldDecl 0x55edfa7e1080 <line:6:3, col:8> col:8 f1 'uint':'unsigned int'
|   `-HLSLParsedSemanticAttr 0x55edfa7e10d0 <col:13> "C" 0
|-CXXRecordDecl 0x55edfa7e1188 <line:9:1, line:12:1> line:9:8 referenced struct S1 definition
| |-DefinitionData pass_in_registers aggregate standard_layout trivially_copyable pod trivial literal
| | |-DefaultConstructor exists trivial needs_implicit
| | |-CopyConstructor simple trivial has_const_param needs_implicit implicit_has_const_param
| | |-MoveConstructor exists simple trivial needs_implicit
| | |-CopyAssignment simple trivial has_const_param needs_implicit implicit_has_const_param
| | |-MoveAssignment exists simple trivial needs_implicit
| | `-Destructor simple irrelevant trivial needs_implicit
| |-PackedAttr 0x55edfa7e1230 <<invalid sloc>> Implicit
| |-CXXRecordDecl 0x55edfa7e12f0 <col:1, col:8> col:8 implicit struct S1
| |-FieldDecl 0x55edfa7e13d8 <line:10:3, col:6> col:6 f0 'S0'
| `-FieldDecl 0x55edfa7e1480 <line:11:3, col:6> col:6 f1 'S0'
|   `-HLSLParsedSemanticAttr 0x55edfa7e14d0 <col:11> "B" 0
`-FunctionDecl 0x55edfa7e18b0 <line:17:1, line:20:1> line:17:6 main 'void (S1, S1)'
  |-ParmVarDecl 0x55edfa7e1668 <col:11, col:14> col:14 p0 'S1'
  | |-HLSLParsedSemanticAttr 0x55edfa7e16d0 <col:19> "D" 0
  | |-HLSLAppliedSemanticAttr 0x55edfa7e1a18 <col:19> "D" 0
  | |-HLSLAppliedSemanticAttr 0x55edfa7e1a60 <col:19> "D" 1
  | |-HLSLAppliedSemanticAttr 0x55edfa7e1aa8 <col:19> "D" 2
  | `-HLSLAppliedSemanticAttr 0x55edfa7e1af0 <col:19> "D" 3
  |-ParmVarDecl 0x55edfa7e1760 <col:22, col:25> col:25 p1 'S1'
  | |-HLSLAppliedSemanticAttr 0x55edfa7e1b38 <line:5:13> "A" 0
  | |-HLSLAppliedSemanticAttr 0x55edfa7e1bb0 <line:6:13> "C" 0
  | |-HLSLAppliedSemanticAttr 0x55edfa7e1bf8 <line:11:11> "B" 0
  | `-HLSLAppliedSemanticAttr 0x55edfa7e1c40 <col:11> "B" 1
  |-CompoundStmt 0x55edfa7e1c88 <line:17:29, line:20:1>
  |-HLSLNumThreadsAttr 0x55edfa7e1980 <line:16:2, col:20> 1 1 1
  `-HLSLShaderAttr 0x55edfa7e19e8 <line:17:1> Implicit Compute

[Keenuts]

@tex3d last comments explains what I have for the refactoring, which is IMO an improvement from what we have today (as it supports struct reuse).

What I hoped was to attach additional attributes as required to each HLSLAppliedSemanticAttr. An example could be a VkLocationAttr if we have a fixed location for a specific semantic field or maybe a DXILSignatureFieldInfo where you can add the bits you need for shader signature?