Update the calling convention and UnmanagedCallersOnly attribute. #3441

333fred · 2020-05-08T23:15:49Z

This adds the changes to extensible calling conventions and support for UnmanagedCallersOnlyAttribute.

tannergooding · 2020-05-08T23:44:58Z

proposals/function-pointers.md

+the method and then invoke that pointer.
+* It is an error to apply the attribute to anything other than a static method. The C# compiler will mark any non-static
+methods imported from metadata with this attribute as unsupported by the language.
+* It is an error to have non-blittable types as parameters or the return type of a method marked with the attribute.


The language doesn't, afaik, have a concept of "blittable" today; only "unmanaged". Is it introducing the former concept or using the latter?

I mean to write unmanaged, will fix.

Will the same apply to unmanaged function pointers or just UnmanagedCallersOnlyAttribute?

tannergooding · 2020-05-08T23:46:01Z

proposals/function-pointers.md

-// This method will be invoked using the stdcall calling convention
-delegate* stdcall<int, int>;
+// This method will be invoked using the stdcall calling convention, and suppresses GC transition
+delegate* unmanaged[CallConvStdCall, CallConvSuppressGCTransition] <int, int>;


I take it we are not allowing unmanaged[StdCall, SuppressGCTransition] then? I don't remember a decision being made here, but I may have missed that bit 😄

I went for simplicity of implementation, I'll add a consideration note.

Thanks, it's mostly a convenience thing but I think it would help greatly with readability and with typing when you have hundreds of function pointers you are declaring/reviewing (such as DirectX which is all COM ThisCall + StdCall)...

tannergooding

LGTM

AaronRobinsonMSFT · 2020-05-09T00:20:14Z

proposals/function-pointers.md

@@ -169,7 +178,7 @@ In an unsafe context, a method `M` is compatible with a function pointer type `F
 - For each `ref`, `out`, or `in` parameter, the parameter type in `M` is the same as the corresponding parameter type in `F`.


D is mentioned above. Should that be updated to F?

AaronRobinsonMSFT · 2020-05-09T00:23:13Z

proposals/function-pointers.md

+modopt on the return type of the function pointer. For any other `CallConv` type or combination of such types, the compiler
+emits a calling convention bit of Unmanaged (0x9), and encodes all `CallConv` types specified as the first modopts on the return
+type of the function pointer. What calling conventions and combinations are valid is determined by the runtime and platform of
+final execution, and no validation is performed that a valid combination of calling conventions has been specified beyond


What calling conventions and combinations are valid is determined by the runtime and platform of final execution

/cc @lambdageek

proposals/function-pointers.md

Co-authored-by: Jan Kotas <[email protected]>

svick · 2020-05-09T06:41:05Z

proposals/function-pointers.md

+// This method will be invoked using the stdcall calling convention, and suppresses GC transition
+delegate* unmanaged[CallConvStdCall, CallConvSuppressGCTransition] <int, int>;


It looks like there is a distinction between the calling convention (like StdCall) and calling convention "modifier" (like SuppressGCTransition), but this proposal ignores that.

Would it make sense to somehow perform basic checking based on that, so that e.g. the nonsensical unmanaged[CallConvCdecl, CallConvStdCall] did not compile? Even if the compiler didn't understand exactly which combinations of calling conventions and their modifiers are allowed, I think such basic checking could still be worthwhile.

It's not readily possible to know what combinations are valid and what are not or what will/wont be in the future. For example thiscall can be combined with basically any other convention is in some cases (thiscall+stdcall is the default for x86 COM, for example).

It's easier to just allow any combination and let the runtime decide.

Would it make sense to somehow perform basic checking based on that

@svick This concern was raised during design. The reason for not checking is an attempt to avoid having to update the compiler whenever a new combination is supported by the runtime. As @tannergooding mentions there are some combinations that could be described as a combination of multiple CallConv* types. Letting the implementing runtime decide what it supports avoids encoding a support matrix in more than one location (e.g. Roslyn and runtime) and lessens the time to market for consumption of those combinations.

The counter argument here is that deferring the error until run time is less than ideal for confidence in a compiled assembly. We can all appreciate that concern. The benefit of quicker adoption of desired combinations in an already advanced interop scenario outweighed the cost of degraded compile time validation. This is why the decision was made.

@AaronRobinsonMSFT @tannergooding I get that hardcoding the full support matrix into the compiler is undesirable.

What I was proposing is that there would be two kinds of CallConv: "base" (like Cdecl or StdCall) and "modifier" (like Thiscall or SuppressGCTransition). An unmanaged function pointer could then have:

Zero or one base CallConv.

Zero or more modifier CallConv.

I think that this way, all valid combinations will still be allowed while many invalid combination will be disallowed. Or am I wrong?

Though thinking about it some more, I think it would actually be possible to encode the support matrix into the metadata of the corelib reference assembly: each base CallConv could have an attribute that specified the modifier CallConvs that it allows, or even the combination of modifier CallConv it allows.

Using this approach, the compiler can know the support matrix, even though altering the support matrix does not involve updating the compiler.

That would still require updating the compiler any time a new convention is released. Having an analyzer that flags potentially bad or unsupported combinations is likely a much better alternative as it is more trivially updated, shipped, and ignored (if desired).

The support might also differ across various runtime implementations. That is, while CoreCLR might support X, Y, and Z; you might have another runtime like Unity or a CIL to LLVM transpiler which supports a different set (or different combinations).

@tannergooding

That would still require updating the compiler any time a new convention is released.

It wouldn't, but I forgot to explain that: the compiler would differentiate between base and modifier CallConv based on metadata. That could be represented by a base class of the CallConv class (e.g. public class CallConvThiscall : ModifierCallConv { … }), or an attribute applied to the CallConv class.

The support might also differ across various runtime implementations.

If they use the same corlib reference assembly, yes, that would be a problem.

That would still require updating the compiler any time a new convention is released.

I've thought a lot about this and I keep asking myself the following: is that so bad? The compiler and runtime release as a pair now. Updating the calling convention is a small amount of work, or would be if we designed for this future. So is it really that bad if we said that every time the runtime adds a new calling convention that we have to change the compiler to support it?

There are many runtime failure modes for interop that have complex conditions and that the compiler does not check for today. One example from many - the compiler does not check whether MarshalAs makes sense for given argument type in regular PInvokes. We could duplicate the runtime checks for all these in the compiler, but the value of it seems very low. I do not think that the support matrix for the unmanaged calling convention modifiers should be on different plan from the rest of interop.

AlekseyTs · 2020-05-09T15:39:04Z

proposals/function-pointers.md

@@ -78,6 +88,7 @@ Restrictions:
 - Custom attributes cannot be applied to a `delegate*` or any of its elements.
 - A `delegate*` parameter cannot be marked as `params`
 - A `delegate*` type has all of the restrictions of a normal pointer type.
+- Pointer arithmetic cannot be performed directly on pointer types.


on pointer types [](start = 50, length = 16)

On function pointer types? #Closed

AlekseyTs · 2020-05-09T15:44:34Z

proposals/function-pointers.md

@@ -114,7 +121,9 @@ funcptr_return_modifier
 ```

 The `unmanaged` calling convention represents the default calling convention for native code on the current platform, and is encoded as winapi.
-All `calling_convention`s are contextual keywords when preceded by a `delegate*`.
+All `identifer`s in the `unmanaged` case of the `calling_convention_specifier` must start with `CallConv`, and come from the
+`System.Runtime.CompilerServices` namespace in the program's core library (defined as one library that references no dependencies and defines


Identifiers cannot really come from a namespace. Perhaps we should say that the identifier must match the name of a type in that namespace instead? #Closed

Instead of come from I suggest bind to a type in

In reply to: 422510659 [](ancestors = 422510659)

AlekseyTs · 2020-05-09T15:52:33Z

proposals/function-pointers.md

+* `System.Runtime.CompilerServices.CallConvThiscall`
+
+If the identifier specified for the `unmanaged` calling convention binds to one of these types, then the function pointer
+is emitted with the calling convention bit set to the appropriate value, and encodes the calling convention type as the first


with the calling convention bit set to the appropriate value [](start = 11, length = 60)

We should be specific what is the value. #Closed

AlekseyTs · 2020-05-09T15:56:03Z

proposals/function-pointers.md

+
+If the identifier specified for the `unmanaged` calling convention binds to one of these types, then the function pointer
+is emitted with the calling convention bit set to the appropriate value, and encodes the calling convention type as the first
+modopt on the return type of the function pointer. For any other `CallConv` type or combination of such types, the compiler


Regarding "as the first modopt". I do not believe there is such a requirement. I think we should simply say that the modopt is added to the set of custom modifiers at the beginning of the function pointer signature. #Closed

AlekseyTs · 2020-05-09T15:57:20Z

proposals/function-pointers.md

+
+If the identifier specified for the `unmanaged` calling convention binds to one of these types, then the function pointer
+is emitted with the calling convention bit set to the appropriate value, and encodes the calling convention type as the first
+modopt on the return type of the function pointer. For any other `CallConv` type or combination of such types, the compiler


on the return type [](start = 7, length = 18)

"on the return type" is also not accurate, the modifier can be on ref rather than on type. #Closed

AlekseyTs · 2020-05-09T15:59:46Z

proposals/function-pointers.md

+If the identifier specified for the `unmanaged` calling convention binds to one of these types, then the function pointer
+is emitted with the calling convention bit set to the appropriate value, and encodes the calling convention type as the first
+modopt on the return type of the function pointer. For any other `CallConv` type or combination of such types, the compiler
+emits a calling convention bit of Unmanaged (0x9), and encodes all `CallConv` types specified as the first modopts on the return


as the first modopts on the return [](start = 94, length = 34)

Same comment here. And we shouldn't specify any relative order for modifiers because in case of overriding/implementing the syntax doesn't really define the order. #Closed

AlekseyTs · 2020-05-09T16:01:40Z

proposals/function-pointers.md

+type of the function pointer. What calling conventions and combinations are valid is determined by the runtime and platform of
+final execution, and no validation is performed that a valid combination of calling conventions has been specified beyond
+ensuring that all calling convention types come from the right namespace in the core library of the program. If the return
+type of a pointer is by `ref`, then all calling conventions will be encoded after the ref specifier.


I do not believe this is accurate. #Closed

No, this isn't accurate. These modifiers must directly follow ParamCount in the method signature.

AlekseyTs · 2020-05-09T16:03:43Z

proposals/function-pointers.md

+ensuring that all calling convention types come from the right namespace in the core library of the program. If the return
+type of a pointer is by `ref`, then all calling conventions will be encoded after the ref specifier.
+
+When interpreting a function pointer in metadata, all modopts that start with `CallConv` and come from the


all modopts [](start = 50, length = 11)

I think this doesn't quite match the latest proposal discussed on the internal thread. #Closed

AlekseyTs · 2020-05-09T16:08:28Z

proposals/function-pointers.md

+* It is an error to have non-blittable types as parameters or the return type of a method marked with the attribute.
+* It is an error to convert a method marked with the attribute to a delegate type.
+* The calling convention specified by the attribute contributes to the calling convention the compiler recognizes when
+a method is converted to a function pointer.


How exactly compiler recognizes them, what do they affect? How the attribute is defined? #Closed

AlekseyTs · 2020-05-09T16:14:10Z

proposals/function-pointers.md

@@ -169,7 +178,7 @@ In an unsafe context, a method `M` is compatible with a function pointer type `F
 - For each `ref`, `out`, or `in` parameter, the parameter type in `M` is the same as the corresponding parameter type in `F`.
 - If the return type is by value (no `ref` or `ref readonly`), an identity, implicit reference, or implicit pointer conversion exists from the return type of `F` to the return type of `M`.
 - If the return type is by reference (`ref` or `ref readonly`), the return type and `ref` modifiers of `F` are the same as the return type and `ref` modifiers of `M`.
- The calling convention of `M` is the same as the calling convention of `F`.
+- The calling convention of `M` is the same as the calling convention of `F`. This includes both the calling convention bit, as well as any calling convention flags specified in the unmanaged identifier.


This includes both the calling convention bit, as well as any calling convention flags specified in the unmanaged identifier. [](start = 78, length = 125)

I think this doesn't quite match the last proposal discussed on the internal thread. We need to specify precise rules for determining if calling conventions are compatible. Also, I am not sure if talking about that in syntactic terms ("calling convention flags specified in the unmanaged identifier") is the right approach. #Closed

AlekseyTs · 2020-05-09T16:16:49Z

Done with review pass (iteration 2) #Closed

jaredpar · 2020-05-11T13:11:12Z

proposals/function-pointers.md

+ensuring that all calling convention types come from the right namespace in the core library of the program. If the return
+type of a pointer is by `ref`, then all calling conventions will be encoded after the ref specifier.
+
+When interpreting a function pointer in metadata, all modopts that start with `CallConv` and come from the


Is this truly "all modopts" or is it ones that appear in specific locations?

jaredpar · 2020-05-11T13:11:38Z

proposals/function-pointers.md

+type of the function pointer. What calling conventions and combinations are valid is determined by the runtime and platform of
+final execution, and no validation is performed that a valid combination of calling conventions has been specified beyond
+ensuring that all calling convention types come from the right namespace in the core library of the program. If the return
+type of a pointer is by `ref`, then all calling conventions will be encoded after the ref specifier.


Suggested change

type of a pointer is by `ref`, then all calling conventions will be encoded after the ref specifier.

type of a pointer is by `ref`, then all calling conventions will be encoded after the `ref` specifier.

jaredpar · 2020-05-11T13:12:22Z

proposals/function-pointers.md

+`System.Runtime.CompilerServices` namespace in the core library are considered to be part of the calling convention of the
+function pointer.
+
+### UnmanagedCallersOnlyAttribute


Consider listing the FQN of this type in this section.

davidwrighton

Please fix the custom modifier location in the method signature signature.

davidwrighton · 2020-05-11T19:09:37Z

proposals/function-pointers.md

+type of the function pointer. What calling conventions and combinations are valid is determined by the runtime and platform of
+final execution, and no validation is performed that a valid combination of calling conventions has been specified beyond
+ensuring that all calling convention types come from the right namespace in the core library of the program. If the return
+type of a pointer is by `ref`, then all calling conventions will be encoded after the ref specifier.


No, this isn't accurate. These modifiers must directly follow ParamCount in the method signature.

…sign, LDM decisions, and PR feedback.

333fred · 2020-06-30T23:06:47Z

@AlekseyTs @davidwrighton @jkotas @jaredpar I've updated the proposal with the latest design decisions. Please let me know if there's any more feedback.

AaronRobinsonMSFT · 2020-06-30T23:14:29Z

proposals/function-pointers.md

+signature. As a note, these rules mean that users cannot prefix these `identifier`s with `CallConv`, as that will result
+in looking up `CallConvCallConvVectorCall`.
+
+When interpreting metadata, the we first look at the `CallKind`. If it is anything other than `unmanaged ext`, we ignore all


~~the we~~ -> "we"

AaronRobinsonMSFT · 2020-06-30T23:16:11Z

proposals/function-pointers.md

+
+It is an error to attempt to use a function pointer with a `CallKind` of `unmanaged ext` if the target runtime does not
+support the feature. This will be determined by looking for the presence of the
+`System.Runtime.CompilerServices.RuntimeFeature.UnmanagedCallKind` constant. If this constant is present, the runtime is


I thought the presence of the UnmanagedCallersOnlyAttribute was going to be enough here?

I see the note below.

I don't particularly want to condition the support based on that attribute, as I think they're orthogonal and we shouldn't tie them together, but we can discuss that Thursday in design review :).

AlekseyTs · 2020-07-01T03:30:19Z

proposals/function-pointers.md

 - For each value parameter (a parameter with no `ref`, `out`, or `in` modifier), an identity conversion, implicit reference conversion, or implicit pointer conversion exists from the parameter type in `M` to the corresponding parameter type in `F`.
 - For each `ref`, `out`, or `in` parameter, the parameter type in `M` is the same as the corresponding parameter type in `F`.
 - If the return type is by value (no `ref` or `ref readonly`), an identity, implicit reference, or implicit pointer conversion exists from the return type of `F` to the return type of `M`.
 - If the return type is by reference (`ref` or `ref readonly`), the return type and `ref` modifiers of `F` are the same as the return type and `ref` modifiers of `M`.
- The calling convention of `M` is the same as the calling convention of `F`.
+- The calling convention of `M` is the same as the calling convention of `F`. This includes both the calling convention bit, as well as any calling convention flags specified in the unmanaged identifier.


This includes both the calling convention bit, as well as any calling convention flags specified in the unmanaged identifier. [](start = 78, length = 125)

I think we would want to expand on that. In particular, I think we should have a special handling of CallConvCDecl modifier (and the like "special" legacy modifiers) in presence of a cdecl bit, as apposed to in presence of unmanaged bit (what ever the new bit we are going to use). One of the reasons, is that, I think, we would want to support overriding a method with a cdecl with modifier function pointer (C++ creates those) by a method with just cdecl function pointer in it. While looking for an override, we should make sure calling conventions match, once we find the matching override, the normal process will inherit the modifiers. Same goes for interface implementations. #Closed

I see that you expanded on that in a section below. Looks reasonable.

In reply to: 448095465 [](ancestors = 448095465)

AlekseyTs

LGTM (iteration 3)

tannergooding

LGTM and matches what I recall from the discussion

davidwrighton

This looks right. I'm excited to see this feature finish up!

davidwrighton · 2020-07-01T19:57:08Z

proposals/function-pointers.md

+
+// This method will be invoked using whatever the default unmanaged calling convention on the runtime
+// platform is. This is platform and architecture dependent and is determined by the CLR at runtime.
+delegate* unmanged<int, int>;


unmanaged should be spelled unmanaged not unmanged. There are several places with this error.

davidwrighton · 2020-07-01T20:07:10Z

proposals/function-pointers.md

+
+// This method will be invoked using whatever the default unmanaged calling convention on the runtime
+// platform is. This is platform and architecture dependent and is determined by the CLR at runtime.
+delegate* unmanged<int, int>;


unmanged should be unmanaged, both here, and in the next example.

Update the calling convention and UnamangedCallersOnly attribute.

fc347a5

333fred requested review from jaredpar, gafter, jkotas, tannergooding, AlekseyTs and AaronRobinsonMSFT May 8, 2020 23:15

tannergooding reviewed May 8, 2020

View reviewed changes

tannergooding approved these changes May 8, 2020

View reviewed changes

AaronRobinsonMSFT reviewed May 9, 2020

View reviewed changes

jkotas reviewed May 9, 2020

View reviewed changes

proposals/function-pointers.md Outdated Show resolved Hide resolved

jkotas approved these changes May 9, 2020

View reviewed changes

Update proposals/function-pointers.md

d073319

Co-authored-by: Jan Kotas <[email protected]>

333fred changed the title ~~Update the calling convention and UnamangedCallersOnly attribute.~~ Update the calling convention and UnmanagedCallersOnly attribute. May 9, 2020

svick reviewed May 9, 2020

View reviewed changes

AlekseyTs reviewed May 9, 2020

View reviewed changes

jaredpar approved these changes May 11, 2020

View reviewed changes

davidwrighton requested changes May 11, 2020

View reviewed changes

tannergooding mentioned this pull request Jun 1, 2020

Function pointers and GC dotnet/runtime#37262

Closed

Update the calling convention sections with feedback from internal de…

0758215

…sign, LDM decisions, and PR feedback.

jkotas approved these changes Jun 30, 2020

View reviewed changes

AaronRobinsonMSFT reviewed Jun 30, 2020

View reviewed changes

AlekseyTs reviewed Jul 1, 2020

View reviewed changes

AlekseyTs approved these changes Jul 1, 2020

View reviewed changes

tannergooding approved these changes Jul 1, 2020

View reviewed changes

davidwrighton approved these changes Jul 1, 2020

View reviewed changes

Fix typo.

2ca2a15

333fred merged commit 1bb4548 into dotnet:master Jul 1, 2020

333fred deleted the update-func-ptrs branch July 1, 2020 22:02

jkotas mentioned this pull request Dec 14, 2022

Function pointer design dotnet/designs#282

Merged

		@@ -169,7 +178,7 @@ In an unsafe context, a method `M` is compatible with a function pointer type `F
		- For each `ref`, `out`, or `in` parameter, the parameter type in `M` is the same as the corresponding parameter type in `F`.

		// This method will be invoked using the stdcall calling convention, and suppresses GC transition
		delegate* unmanaged[CallConvStdCall, CallConvSuppressGCTransition] <int, int>;

	type of a pointer is by `ref`, then all calling conventions will be encoded after the ref specifier.
	type of a pointer is by `ref`, then all calling conventions will be encoded after the `ref` specifier.

Update the calling convention and UnmanagedCallersOnly attribute. #3441

Update the calling convention and UnmanagedCallersOnly attribute. #3441

Conversation

333fred commented May 8, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tannergooding left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlekseyTs May 9, 2020 • edited Loading

Choose a reason for hiding this comment

AlekseyTs May 9, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlekseyTs May 9, 2020 • edited Loading

Choose a reason for hiding this comment

AlekseyTs May 9, 2020 • edited Loading

Choose a reason for hiding this comment

AlekseyTs May 9, 2020 • edited Loading

Choose a reason for hiding this comment

AlekseyTs May 9, 2020 • edited Loading

Choose a reason for hiding this comment

AlekseyTs May 9, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlekseyTs May 9, 2020 • edited Loading

Choose a reason for hiding this comment

AlekseyTs May 9, 2020 • edited Loading

Choose a reason for hiding this comment

AlekseyTs May 9, 2020 • edited Loading

Choose a reason for hiding this comment

AlekseyTs commented May 9, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davidwrighton left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

333fred commented Jun 30, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlekseyTs Jul 1, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlekseyTs left a comment

Choose a reason for hiding this comment

tannergooding left a comment

Choose a reason for hiding this comment

davidwrighton left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlekseyTs May 9, 2020 •

edited

Loading

AlekseyTs May 9, 2020 •

edited

Loading

AlekseyTs May 9, 2020 •

edited

Loading

AlekseyTs May 9, 2020 •

edited

Loading

AlekseyTs May 9, 2020 •

edited

Loading

AlekseyTs May 9, 2020 •

edited

Loading

AlekseyTs May 9, 2020 •

edited

Loading

AlekseyTs May 9, 2020 •

edited

Loading

AlekseyTs May 9, 2020 •

edited

Loading

AlekseyTs May 9, 2020 •

edited

Loading

AlekseyTs commented May 9, 2020 •

edited

Loading

AlekseyTs Jul 1, 2020 •

edited

Loading