Support IDynamicInterfaceCastable with shared generic code

[MichalStrehovsky]

Below snippet will fail with a NullRef while trying to do generic lookup in IInterfaceCastableImpl. This is because we didn't provide generic context.

The implementation strategy will be somewhere along the lines of:

• When generating the sealed vtable, add a delta (like we do for fat function pointers) to canonical entries on IDynamicCastable implementations so that we know more is needed at runtime.
• Do something to the file format so that we can express "the index of the interface through which implementation is provided" to cover [DynIntfCastableImpl] interface IFooImpl : ISomething<object>, ISomething<string> { } when both ISomething provide default implementations.
• Whenever a IDynamicCastable implementation is looked up at runtime and the found method has the delta bit set, create a thunkpool thunk that puts the "interface through which implementation is provided" in the TLS slot.
• Make a cache for the thunkpool thunks.
• Update the shared generic helper to take the value from the TLS slot.

This is a bunch of work.

It's unclear to me if anyone uses IDynIntfCast with generics. It doesn't work great with generics. E.g. interface variance is broken.

using System;
using System.Runtime.InteropServices;

var s = (IInterface<string>)new CastableClass<IInterface<string>, IInterfaceCastableImpl<string>>();
s.GetCookie();

class CastableClass<TInterface, TImpl> : IDynamicInterfaceCastable
{
    RuntimeTypeHandle IDynamicInterfaceCastable.GetInterfaceImplementation(RuntimeTypeHandle interfaceType)
        => typeof(TImpl).TypeHandle;
    bool IDynamicInterfaceCastable.IsInterfaceImplemented(RuntimeTypeHandle interfaceType, bool throwIfNotImplemented)
        => true;
}

interface IInterface<out T>
{
    string GetCookie();
}

[DynamicInterfaceCastableImplementation]
interface IInterfaceCastableImpl<T> : IInterface<T>
{
    string IInterface<T>.GetCookie() => typeof(T).ToString();
}

[jkoritzinsky]

C#/WinRT uses IDIC with generics to an extent (and they're looking at figuring out a way to handle generic variance themselves for the few cases they have), so at least the basics need to be covered. (#1443 might cover all the cases required).

[MichalStrehovsky]

I think we're going to hit it in the Marshaler<T>.FromAbi calls used to get return values in CsWinRT.

Btw, does generic variance actually work with IDIC? If I add these two lines at the end of the top-level main above:

IInterface<object> s2 = s;
s2.GetCookie();

I get "'Type 'IInterfaceCastableImpl`1[System.String]' returned by IDynamicInterfaceCastable does not implement the requested interface 'IInterface`1[System.Object]'.'". My intuition would say that this should be valid.

[jkoritzinsky]

If you get that exception on the GetCookie call, then you're seeing the same things C#/WinRT is seeing. Variance is not intrinsically supported in the system today, but covariance can be emulated manually by having the implementation of GetInterfaceImplementation look at the known "supported" types and using reflection to determine if the requested type (IInterface<object> in this case) can be supported by one of the known-supported implementation interfaces (the implementation for IInterface<string> in your example).

This is definitely not fast (though precalculating it can help), but it's a reasonable approximation of what the old built-in WinRT support used to do (and the path I have advised C#/WinRT to go down when they contacted me about issues with covariance).

[MichalStrehovsky]

I think if we didn't block the variant case here:

runtime/src/coreclr/System.Private.CoreLib/src/System/Runtime/InteropServices/DynamicInterfaceCastableHelpers.cs

Lines 37 to 38 in 918e6a9

	if (!implType.ImplementInterface(interfaceType))
	throw new InvalidOperationException(SR.Format(SR.IDynamicInterfaceCastable_DoesNotImplementRequested, implType, interfaceType));

, it might "just work".

If I understand what you wrote correctly, does it mean that CsWinRT will actually go and MakeGenericType a IInterfaceCastableImpl<object> to answer the cast? Would the statically referenced IInterfaceCastableImpl<string> be able to do the job if we didn't explicitly block it?

[jkoritzinsky]

I think if we didn't block the variant case here: dotnet/runtime@918e6a9/src/coreclr/System.Private.CoreLib/src/System/Runtime/InteropServices/DynamicInterfaceCastableHelpers.cs#L37-L38, it might "just work".

It would be worth trying to extend that check to also allow the variant case. I wouldn't want to remove that check completely.

If I understand what you wrote correctly, does it mean that CsWinRT will actually go and MakeGenericType a IInterfaceCastableImpl<object> to answer the cast? Would the statically referenced IInterfaceCastableImpl<string> be able to do the job if we didn't explicitly block it?

I believe that was the direction we were going down, yes.

[AaronRobinsonMSFT]

I think if we didn't block the variant case here:

runtime/src/coreclr/System.Private.CoreLib/src/System/Runtime/InteropServices/DynamicInterfaceCastableHelpers.cs

Lines 37 to 38 in 918e6a9

	if (!implType.ImplementInterface(interfaceType))
	throw new InvalidOperationException(SR.Format(SR.IDynamicInterfaceCastable_DoesNotImplementRequested, implType, interfaceType));

, it might "just work".

Agreed. This check is a bit too aggressive in my opinion. There are other issues here but that really should be

if (!implType.IsAssignableTo(interfaceType))
    throw new InvalidOperationException(SR.Format(SR.IDynamicInterfaceCastable_DoesNotImplementRequested, implType, interfaceType));

I will update this tomorrow and add some tests. Do we have any of these variance issues tracked in dotnet/runtime? If not, I'd like to see an issue on this.

[MichalStrehovsky]

Filed #58619