[NativeAOT] don't generate __GetFieldHelper if 'boxed' struct overrides object Equals

[NinoFloris]

Tangential follow up on #116301

If we cannot prevent constructs like typeof from marking structs as boxed we should make it possible to limit what a boxed struct implies.

Given the following code I would expect there to be no record of __GetFieldHelper in the mstat:

using System.Diagnostics.CodeAnalysis;
using System.Runtime.CompilerServices;

_ = TypeOf<Foo>();

[MethodImpl(MethodImplOptions.NoInlining)]
static Type TypeOf<T>() => typeof(T);

struct Foo
{
    public override int GetHashCode() => throw new NotSupportedException();
    public override bool Equals([NotNullWhen(true)] object? obj) => throw new NotSupportedException();
}

Once fixed it would be *a* mitigation for large __GetFieldHelpers being emitted.

Ideally though there would be an attribute like OmitObjectMethodImpls (or something more narrow like OmitObjectEquality) which could be applied to a type (or module even?).

Something that would make runtimes do the cheapest thing to produce a NotSupportedException in object's virtual methods for the affected types.

For NativeAOT that could be a bit flag in the type info or some __GetFieldHelper sentinel return value.

Having an intrinsic attribute would also be preferable to needing to override two or more methods (though worst case this could be handled by a source generator).

[dotnet-policy-service]

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

[MichalStrehovsky]

The reason we currently don't do that is because people sometimes do:

struct Foo
{
    public override int GetHashCode() => base.GetHashCode();
}

and then we need to still make sure __GetFieldHelper is there. If we add analysis that ensures there's not a single call ValueType::GetHashCode/call ValueType::Equals instruction in the whole program, we could get rid of the override.

[NinoFloris]

Wouldn't analyzing whether base is used in the overriding body be better? It'd just be another form of method dependency analysis. I'm surprised it's not being done already, maybe I'm missing some hidden complexity with that approach?

[MichalStrehovsky]

Wouldn't analyzing whether base is used in the overriding body be better? It'd just be another form of method dependency analysis. I'm surprised it's not being done already, maybe I'm missing some hidden complexity with that approach?

We support compiling arbitrary IL, not just subset that C# compiler emits. In IL, it's possible to direct non-virtual call to a base method from anywhere (one is not limited by what the base keyword allows in C#). We try to be careful not to introduce optimizations that break non-C# languages (or a potential future C# version that could advantage of this).

[NinoFloris]

Right, I forgot that you can access any base implementations of virtual methods from anywhere that way.

So the most permissive condition that's still legal would be to check there are no direct calls to the ValueType equality methods.

Where callvirts could be permitted by doing more analysis to check that all structs have implementations for object equality (where base calls would be caught by being a direct call again)?