[DRAFT] [clr-interp] Fix some interop suite issues

[davidwrighton]

This fixes several issues:

• A bug around usage of HasUnmanagedCallersOnlyAttribute in callstubgenerator.cpp (This is also a separate PR, since I'm convinced that fix is correct.)
• Platform detection of IsBuiltInComEnabled in the presence of interpreter support
• A bug in delegate creation around creating a delegate to a function which is marked with [UnmanagedCallersOnly]. I need to validate that we need to actually fix this or if the current check (which isn't on the slow path) can be adapted to work in the coreclr interpreter in some way.

[davidwrighton]

@AaronRobinsonMSFT @jkoritzinsky do you have an opinion on the check of HasUnmanagedCallersOnlyAttribute in the delegate constructor. We currently have a check for it in optimized delegate construction, which is almost always used by the JIT, but I need to know if we really need that to work, or if it's just a convenience feature that it fails.

[davidwrighton]

/azp run runtime-interpreter

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Most delegate constructor go via optimized path, so this is incomplete.

Our strategy has been to delay this check until the UnmanagedCallersOnly method is actually called and produce a fail-fast with a good error message in that case:

runtime/src/coreclr/vm/jithelpers.cpp

Line 997 in a83d76a

void ReversePInvokeBadTransition()

[davidwrighton]

The optimized path already has this check. The question is should the slow path ALSO have the check.

[davidwrighton]

The optimized path already has this check. The question is should the slow path ALSO have the check.

[jkotas]

Where is this check on the optimized path?

[davidwrighton]

It's in the optimized delegate creation path called by the jit. I could replicate that if needed in the interpreter compiler. Search for the comment. I copied it verbatim.

[davidwrighton]

It's in the optimized delegate creation path called by the jit. I could replicate that if needed in the interpreter compiler. Search for the comment. I copied it verbatim.

[jkotas]

I see it now. I think it is an oversight that we check for it on the fast path. It is inconsistent with the lazy check that we do everywhere else. For example, you can create delegate pointing to UMCO via reflection just fine (it will fail once you try to call it):

public class Program
{
    static void Main()
    {
        typeof(Program).GetMethod("Test").CreateDelegate<Action>();
    }

    [UnmanagedCallersOnly]
    public static void Test() { }
}