Discussion: Open Issues in Function Pointers

[333fred]

Issues in Function Pointers

Creating an issue for LDM topic on 4/1/20.

• Confirm NativeCallableAttribute support:

  • This attribute can be applied to methods to indicate that a method can be called with a specific calling convention.
  • Has the following restrictions that need to be applied from C#:
    • Cannot be called from managed code.
    • Parameters must be blittable
    • Must be static
    • Method cannot be generic or in a generic class
    • Cannot be called or used as in a delegate creation
  • When taking the address of a method marked with this attribute, we will use it to determine the calling convention of the method.
  • NativeCallableAttribute should be a public API runtime#32462

• Supporting extensible calling conventions:

  • Motivation: the runtime team would like to add support for more calling conventions in the future, without necessarily having to rev the language (and make more work in the compiler).
  • Proposal:
    • 335 specifies a calling convention bit that means "calling convention is defined by a modreq on the return type".
    • We specify that calling convention keywords are platform-dependent.
    • The calling convention comes from a type in the System.Runtime.CompilerServices namespace. Type names that start with CallConv are considered.
    • These types must come from CorLib.
    • You can put 1 and only 1 calling convention on the function pointer.
    • If the calling convention is one of the ones understood by the platform today (managed, thiscall, stdcall, cdecl), we'll use the existing bit.
    • Otherwise, we use the new bit and modreq.
  • For C# syntax here, my proposal is as follows:
    • We strip off the CallConv bit from the front, and use the lowercase version of the remaining part of the name as the convention. This allows us to continue having these be contextual keywords in traditional C# fashion (ie, all lowercase).
    • Alternatively, we can just directly use the text from the remaing characters after CallConv.
      • In this version, we likely want to standardize our existing keyword proposal with the type names in the BCL, so that both Stdcall and stdcall are not options, for example.

• Supporting other attributes on function pointer types.

  • There is a request to support attributes like GCSuppressTransition as part of function pointers (ie, being able to tell the GC that this function pointer call is quick, and it shouldn't do a full managed->native transition).
  • There is no native place in a function pointer type to put this type of information, so the proposal is as follows:
    • We put types specified as modreqs on the return type.
    • Changing these attributes is a breaking change for library authors (because the type is changing).
    • Types used in these attributes must come from the System.Runtime.InteropServices (or some specific namespace, to be worked out with the runtime team. The intent is to make it so that any old type may not be used, just names supported by the runtime.)
  • Syntax proposal (where valid identifiers will be platform-dependent):

  funcptr_type
  : 'delegate' '*' calling_convention? '<' (funcptr_parameter_modifier? type ',')* funcptr_return_modifier? return_type '>'
  ;
  
  calling_convention
  : identifier 
  | '(' identifier ('|' identifier)* ')'
  ;

[YairHalberstadt]

Is the date wrong?

[333fred]

Thanks @YairHalberstadt

[333fred]

This was discussed, closing.