Sadly these attributes are valid in places that aren’t parameters. For example, they can be applied on the members of a struct. When specifying an HLSL entry we require semantics for all scalar variables in the signature so that the we can match up the parameters from driver and user-provided values, but the parameters can be scalars or user defined structs. For example:

struct Pupper {
  int Legs : SomeAnnotation;
  int Ears : SomeOtherAnnotation;
}
...
void main(Pupper P) {...} // valid as an entry

We also allow these annotations (and require them) on return types for entry functions:

int main(...) : SomeAnnotation {...}

Where this all gets really special is that entry functions as passed to drivers have a void(void) signature, but entry functions with the source-specified signature can be called.

I'm trying to handle those cases in D131203 by generating the user-written function as is with C++ mangling, and generating a non-mangled void(void) wrapper that calls the underlying function after populating the annotation values. It is an incomplete implementation, but a starting point.

I _think_ taking the address of the function should consistently give the address of the mangled function since the AST will resolve using C++ mangling rules. I hope that would be the expected behavior even if we exposed pointers in the future since the void(void) entry should only ever be the hardware start point.

I'm sure I'm wrong about this and will regret this speculation in the future...