Some delegate invoke thunks fail to compile with `where T : allows ref struct` delegates

[SingleAccretion]

In a recent downstream merge, I noticed these when compiling S.R.Tests:

  ILC: Method '[S.P.CoreLib]System.Func`2<System.ReadOnlySpan`1<char>,int32>.InvokeObjectArrayThunk(ReadOnlySpan`1<char>)' will always throw because: Invalid IL or CLR metadata
  ILC: Method '[S.P.CoreLib]System.Func`2<System.ReadOnlySpan`1<char>,int32>.InvokeOpenInstanceThunk(ReadOnlySpan`1<char>)' will always throw because: Invalid IL or CLR metadata

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[MichalStrehovsky]

These should not be getting the thunks. Unfortunately, we make this decision based on looking at the type definition, not the specific instantiated type, so we don't detect this new substitution possibility where we should:

runtime/src/coreclr/tools/Common/TypeSystem/IL/DelegateInfo.cs

Lines 137 to 139 in 66ae90f

	// Methods that have a byref-like type in the signature cannot be invoked with the object array thunk.
	// We would need to box the parameter and these can't be boxed.
	// Neither can be methods that have pointers in the signature.

I wonder if it would be easiest to just suppress this message and let it generate the throwing body.

[huoyaoyuan]

These should not be getting the thunks.

Do you mean the thunks should be unreachable?

In coreclr they are reachable in second level of indirection like delegate2 = delegat1.Invoke, see #104731 (comment).

[jkotas]

In coreclr they are reachable in second level of indirection like delegate2 = delegat1.Invoke, see #104731 (comment).

There are number of different delegate thunks/stubs. #104731 is about delegate Invoke method. This issue is about the nativeaot-specific thunks that support System.Linq.Expressions.

[agocke]

What's the priority on fixing this? Will this block a 9.0 scenario or is it just a spurious warning?