[Proposal] System.Runtime.CompilerServices.RuntimeFeature.UnmanagedCallKind

[333fred]

Background and Motivation

With .NET 5, we're going to be adding support for a new CallKind bit (tracked here: #38133). From the compiler side, we need a feature flag to know when the target platform supports that bit, so we can error in cases when it's not supported (like we do with DIMs).

Proposed API

namespace System.Runtime.CompilerServices
{
    public static partial class RuntimeFeature
    {
        /// <summary>
        /// Name of the Portable PDB feature.
        /// </summary>
        public const string PortablePdb = nameof(PortablePdb);
 
#if FEATURE_DEFAULT_INTERFACES
        /// <summary>
        /// Indicates that this version of runtime supports default interface method implementations.
        /// </summary>
        public const string DefaultImplementationsOfInterfaces = nameof(DefaultImplementationsOfInterfaces);
#endif

+       /// <summary>
+       /// Indicates that this version of runtime supports the platform default calling convention.
+       /// </summary>
+       public const string UnmanagedSignatureCallingConvention = nameof(UnmanagedSignatureCallingConvention);
 
        /// <summary>
        /// Checks whether a certain feature is supported by the Runtime.
        /// </summary>
        public static bool IsSupported(string feature)
        {
            switch (feature)
            {
                case PortablePdb:
+               case UnmanagedSignatureCallingConvention:
#if FEATURE_DEFAULT_INTERFACES
                case DefaultImplementationsOfInterfaces:
#endif
                    return true;
                case nameof(IsDynamicCodeSupported):
                    return IsDynamicCodeSupported;
                case nameof(IsDynamicCodeCompiled):
                    return IsDynamicCodeCompiled;
            }
 
            return false;
        }
    }
}

Usage Examples

In the C# compiler for determining errors.

Alternative Designs

N/A

Risks

N/A

[jkotas]

Would it make sense to attach this feature to the presence of UnmanagedCallersOnlyAttribute in the compiler instead of adding this? It is all one bundle of features.

[jkotas]

If we decide to go ahead with this, the name should be synchronized with the name from #38133, e.g. RuntimeFeature.UnmanagedSignatureCallingConvention. There is no "Kind" in the other name.

[terrajobst]

I agree with @jkotas. RuntimeFeatures is intended for cases where there is no managed API the compiler could key this off of. In this case it seems the availability of the attribute is sufficient.

[tannergooding]

In this case it seems the availability of the attribute is sufficient

This would require any runtime that supports the new unmanaged calling convention bit (#38133) to also support UnmanagedCallersOnlyAttribute. I don't think that is necessarily bad, just wanted to ensure it was called out.

[333fred]

Would it make sense to attach this feature to the presence of UnmanagedCallersOnlyAttribute in the compiler instead of adding this? It is all one bundle of features.

Well, it seems inconsistent to me. The fact that the runtime is implementing UmanagedCallersOnlyAttribute at the same time doesn't feel particularly relevant to the calling convention support. For features we key off a type, those types are usually actually relevant to the feature. The presence of IAsyncEnumerable, for example. But being able to write delegate* unmanaged<void> doesn't feel very related to the presence of UnmanagedCallersOnlyAttribute.

This would require any runtime that supports the new unmanaged calling convention bit (#38133) to also support UnmanagedCallersOnlyAttribute. I don't think that is necessarily bad, just wanted to ensure it was called out.

Exactly. It's not necessarily bad, but it feels odd to require these to be tied together when it's a very simple and small API addition to not do so.

[333fred]

If we decide to go ahead with this, the name should be synchronized with the name from #38133, e.g. RuntimeFeature.UnmanagedSignatureCallingConvention. There is no "Kind" in the other name.

Updated.

[jkotas]

The fact that the runtime is implementing UmanagedCallersOnlyAttribute at the same time doesn't feel particularly relevant to the calling convention support.

I believe that there are number of feature bundles that can be more fine grained in theory, but are not for simplicity - to avoid dealing with the theoretical combinations that you have one, but not the other.

For example, static methods on interfaces are tied together with default implementations of interfaces, even though they are fairly independent features. In fact, static methods on interfaces were supported by the runtime since forever, and default implementations of interfaces were added just recently.

[MichalStrehovsky]

I agree with @jkotas. RuntimeFeatures is intended for cases where there is no managed API the compiler could key this off of. In this case it seems the availability of the attribute is sufficient.

If that's the litmus test, should we reconsider RuntimeFeature.CovariantReturnsOfClasses? Since that one can be deduced from the presence of PreserveBaseOverridesAttribute - #35315 (comment). Roslyn is already aware of that attribute since the attribute was a compiler request.

[terrajobst]

Video

• We considered keying it off of the presence of the attribute but the attribute isn't the same feature. Also, the compiler would want the type to exist in corlib (to ensure it's not user defined). That would feel odd, considering all modifiers live in System.Runtime.InteropServices.dll.
• We agree that making that RuntimeFeature a dumping ground for all new compiler features would be bad, but it seems runtime type system constraints would be long to RuntimeFeature.

namespace System.Runtime.CompilerServices
{
    public static partial class RuntimeFeature
    {
        public const string UnmanagedSignatureCallingConvention = nameof(UnmanagedSignatureCallingConvention);
    }
}