ILC considers types as constructed for IsAssignableFrom

[sbomer]

Not sure if this is by design, but it leads to a strange user experience. Repro:

using System.Diagnostics.CodeAnalysis;

typeof(C).IsAssignableFrom(typeof(int));
Helper(null);

static void Helper(I i) => i.Foo();

interface I {
    void Foo();
}

// Uncomment this and there are no warnings
// [RequiresUnreferencedCode("")]
class C : I {
    public void Foo() => RUC(); // Warns with PublishAot

    [RequiresUnreferencedCode("")]
    static void RUC() { }
}

This gives a false positive warning at the call to RUC even though C is never constructed. ILLink doesn't produce this warning. Uncommenting RequiresUnreferencedCode on the class gets rid of the warning, so it looks like we already (correctly) don't consider the reference to C to be a call to the constructor, at least for the purpose of producing analysis warnings.

This causes some warnings in azure-mcp: https://github.com/Azure/azure-cosmos-dotnet-v3/blob/e946c1a24dff26f201ecadde303a66cf5df3af0a/Microsoft.Azure.Cosmos/src/direct/PathsHelper.cs#L767.

@MichalStrehovsky @agocke

[dotnet-policy-service]

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

[MichalStrehovsky]

This is right now by design. The problem is that within the compiler we have two ways to refer to types (MethodTables): constructed form and unconstructed form. They have these properties:

	Unconstructed ("necessary")	Constructed
Base type	✔	✔
Interfaces	✔	✔
GCDesc		✔
VTable		✔
Reflection metadata		✔

Because reflection metadata is only available for the constructed form, it is what we use for typeof. In the past, there were more reasons to use the constructed form (passing unconstructed type to e.g. RuntimeHelpers.GetUninitializedObject in trim unsafe code could lead to GC holes but we now have checks to make sure an exception is thrown instead of creating a GC hole).

In an ideal world we'd have a third form of MethodTable (unconstructed with metadata) that we could use for scenarios like typeof. It might be worth adding.

That said, we also have an existing optimization that tries to look for type equality patterns (typeof(Foo) == foo.GetType() etc.). When we see this pattern, we downgrade the MethodTable used from the typeof to the necessary form (since we know the lack of metadata/GCDesc/vtable is not observable). We could extend this to IsAssignableFrom. This would be useful even if we were to add the third form of MethodTable since we can still trim out the metadata for these.