[NativeAOT] AccessViolationException when making reflection calls over DIMs

[eiriktsarpalis]

Description

I encountered this regression while migrating a library of mine to .NET 9.

Reproduction Steps

Compile and run the following console app as a NAOT application

IType type = new Type<object>();
type.Accept(new MyVisitor());

class Type<T> : IType<T>;

class MyVisitor : IVisitor
{
    public object? Visit<T>(IType<T> _) => typeof(T);
}

//--------------------------------

interface IType
{
    object? Accept(IVisitor visitor);
}

interface IType<T> : IType
{
    object? IType.Accept(IVisitor visitor) => visitor.Visit(this);
}

interface IVisitor
{
    object? Visit<T>(IType<T> type);
}

Expected behavior

Should execute without incident.

Actual behavior

Throws the following exception:

Process terminated. Access Violation: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. The application will be terminated since this platform does not support throwing an AccessViolationException.
   at System.RuntimeExceptionHelpers.FailFast(String, Exception, String, RhFailFastReason, IntPtr, IntPtr) + 0x200
   at System.RuntimeExceptionHelpers.GetRuntimeException(ExceptionIDs) + 0x148
   at System.Runtime.EH.GetClasslibException(ExceptionIDs, IntPtr) + 0x48
   at IType`1.IType.Accept(IVisitor) + 0x18
   at Program.<Main>$(String[] args) + 0x40

Regression?

This is a regression from .NET 8.

Known Workarounds

No response

Configuration

.NET SDK:
 Version:           9.0.100
 Commit:            59db016f11
 Workload version:  9.0.100-manifests.3068a692
 MSBuild version:   17.12.7+5b8665660

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26100
 OS Platform: Windows
 RID:         win-arm64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.100\

Other information

No response

[dotnet-policy-service]

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

[MichalStrehovsky]

So looks like this is already fixed in .NET 10 - #108235 happens to also fix this because it touched the logic just enough. The problem was with us not marking the interface as used.

I'll request a backport.

I also made a pull request that adds this testcase since all tests for #108235 involved IDynamicInterfaceCastable.