Open types can exist as entries in interface map

[davidwrighton]

• While invalid via the ECMA spec, the runtime currently represents a type explicitly instantiated over its own generic type parameters via the open type MethodTable
• This is not strictly correct, as per the spec, these should be represented via an instantiated type, but changing that detail at this time is considered highly risky
• This conflicts with the perf optimization around partial interface loading which uses the open type of an interface to represent a type instantiated in the curiously recurring fashion.
• The fix is to detect types instantiated over generic variables, and make them ineligible for the optimization, and to detect those cases where the optimization is ineligible, and revert back to the non-optimized behavior

Fixes #55323

[trylek]

OMG, that's pretty awful, thanks for fixing this!

[davidwrighton]

Hmm, well, that seems to have caused more problems. I'll have a fix put together for Tuesday.

[NinoFloris]

This is not strictly correct, as per the spec, these should be represented via an instantiated type, but changing that detail at this time is considered highly risky

Should this be tracked to be fixed in a future version?

[davidwrighton]

@NinoFloris Well, the issue that we know of is actually to the runtime internal data structures. Those are not actually visible to customers in a direct fashion. From what I can see, we may have a bug around looking at via reflection the set of interfaces on the open type of one of the types in the new test. However, we've had 16 years with the existing behavior, and no-one has ever noticed. In general, we don't track fixing/identifiying precisely this sort of spec violation without some known impact to a customer.

[NinoFloris]

I understand and from that viewpoint you're probably right if it hasn't come up before. I can only speculate about the potential perf lost by barring these types from this optimization and maybe it's irrelevant :)