[API Compat] Changing a member return type should be detected as a breaking change

[MrJul]

Describe the bug

Changing the return type of a member, whether its a field, property or method isn't detected by the API Compat tool.

To Reproduce

The following zip files has two assemblies, before.dll and after.dll, each with a single class C having three members. The member names are the same for the two assemblies, but their return type is different. These are breaking changes, and will result in MissingFieldException/MissingMemberException/MissingMethodException at runtime.

File: diff.zip

Before.dll:

public class C
{
    public readonly string Field = "f";
    public int Property => 123;
    public double Method() => 45.6;
}

After.dll:

public class C
{
    public readonly int Field = 0;
    public string Property => "p";
    public DateTime Method() => DateTime.Now;
}

Run

apicompat -l=./before.dll -r=./after.dll

Expected: APICompat reports three breaking changes.
Actual: "APICompat ran successfully without finding any breaking changes."

Further technical details

Reproduced with both:

• Latest release: 7.0.400+8e1f76c1f41ecd37935288c617c53342533db704
• Latest nightly build: 9.0.100-alpha.1.23417.7+4249701de6f005c670c7f371141e772d02f89156

@dotnet/area-infrastructure-libraries a new issue has been filed in the ApiCompat area, please triage

[ViktorHofer]

Closing as duplicate of #23907. Feel free to up-vote the original issue.

Just noticed that the other issue only tracks modifiers but not the actual return types. Reopening.

[ViktorHofer]

@ericstj let's discuss what we expect the MemberMustExist rule to catch and what not. I.e. we currently don't include the member type or modifiers, neither the this keyword for extension methods.

We could create separate rules for all these cases but I wonder why not just let the MemberMustExist rule handle this by default.