Compiler behavior when generating code for override that is ambiguous to the runtime

[gafter]

Along with the implementation of covariant returns, we have a bug fix for the code generation strategy when we generate metadata for an override of a method that might otherwise be ambiguous to the runtime. Specifically, in a case such as

class Base<T>
{
    public virtual void M(ref T t) { }
    public virtual void M(out int t) { t = 1; }
}
class Derived : Base<int>
{
    public override void M(ref int t) { }
}

where the two methods would both be inferred as candidates for the overridden method by the runtime, the compiler currently warns

warning CS1957: Member 'Derived.M(ref int)' overrides 'Base<int>.M(ref int)'. There are multiple override candidates at run-time. It is implementation dependent which method will be called.

However, the compiler can produce a “methodimpl” (aka .override) entry in metadata to instruct the runtime precisely which method is overridden, thereby resolving the ambiguity.

This is a change in behavior, and though it is a bug fix it could result in a change in behavior that is unwanted by some clients. In addition, despite being required to by the specification the runtime does not always obey the table entries in metadata (see dotnet/runtime#38119). We are expecting the runtime bug to be fixed in .net 5.

The question is: under what conditions should the compiler

1. emit methodimpl (.override) table entries in metadata so that the metadata is no longer ambiguous.
2. produce a wanrning that the behavior might be ambiguous at runtime.

With regards to (1), note that because the metadata differs from before, and because there is a known bug in some runtimes, it is possible that there exist examples where a program behavior changes from correct to incorrect if we add the methodimpl.

The options that we are considering are:

1. Produce code-gen fix unconditionally. Stop producing the warning.
   Pros: Simplest product code (already implemented in PR).
   Cons: May change behavior on older runtimes (correct to incorrect or vice versa) without warning.
2. Produce code-gen fix if runtime known to support it. Produce warning if runtime not known to support it.
   Pros: Most compatible for older runtimes, most correct for newer runtimes.
   Cons: More code in the product.
3. Produce code-gen fix unconditionally. Always produce the warning.
   Pros: No runtime-version-specific branches in the compiler.
   Cons: May change behavior on older runtimes (correct to incorrect or vice versa) with no change in the warning
   Produces incorrect (false positive) warnings for newer runtimes.
4. Produce code-gen fix unconditionally. Produce warning if runtime not known to support it.
   Pros: Somewhat simpler product code (relative to 2).
   Cons: May change behavior on older runtimes (correct to incorrect or vice versa) with no change in the warning

[gafter]

See also #44067

[gafter]

We decided to go with option 2. We can possibly enhance the warning to suggest moving to .net 5.

[gafter]

Fixed in #44025