-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define documentation comment ID for function pointers #48363
Comments
Whatever we do for pointer types, we should do the same here. Fundamentally, at the runtime level function pointers are just a type of pointer. |
@333fred I don't quite understand how does that help define the format for function pointers. Consider the following table:
The syntax for regular pointers is simple and it's the same everywhere: just append |
I think it should follow the metadata encoding, in order to be language-agnostic. |
Can it not match what's already documented for MSVC? https://docs.microsoft.com/en-us/cpp/build/reference/dot-xml-file-processing?view=msvc-160
There's a note that says MSVC never generates that ID type, but this C++/CLI example: public ref class DocTest {
public:
typedef void (*function_ptr)(char, int);
/// <summary>Test fnptr doc</summary>
void FnptrTest(function_ptr f);
}; generates the following IL sig:
and this XML: <member name="M:DocTest.FnptrTest(=FUNC:System.Void(System.SByte!System.Runtime.CompilerServices.IsSignUnspecifiedByte,System.Int32))">
<summary>Test fnptr doc</summary>
</member> Note that they also define a syntax for Calling convention is also included by MSVC as a I would be very much in favor of keeping as much consistency between the compilers as possible. I have a tool that handles |
If MSVC has a format for these, then I would say that we should follow that precedent. However, we will need to include the calling convention in the signature, as we allow overloading on calling convention: public unsafe class C {
public void M(delegate*<void> ptr) {}
public void M(delegate* unmanaged[Cdecl]<void> ptr) {}
} In particular, we'll have to define something for the |
I just gave it another try, and MSVC does always include a typedef void (__cdecl *function_ptr_cdecl)(int);
typedef void (__stdcall *function_ptr_stdcall)(int);
public ref class C {
public:
/// <summary>Test fnptr cdecl doc</summary>
void M(function_ptr_cdecl f) { }
/// <summary>Test fnptr stdcall doc</summary>
void M(function_ptr_stdcall f) { }
}; outputs: <member name="M:C.M(=FUNC:System.Void(System.Int32))">
<summary>Test fnptr cdecl doc</summary>
</member>
<member name="M:C.M(=FUNC:System.Void(System.Int32))">
<summary>Test fnptr stdcall doc</summary>
</member> According to their specs, I would expect the DocIDs for those to be Would that be workable for the C# side, with the managed calling convention undecorated? Edit: Sorry, I misread your comment, as I think there's a missing no in there. I see now that Roslyn doesn't emit a |
Fixed, thanks. And yes, we'll need it not just for the unmanaged case, but for the rest of the cases as well. MSVC emits modopts in addition to setting the CallKind bit in IL, but we just set the CallKind unless we're overriding a signature that has the modopt. |
For reference, it seems CCI has a syntax that is similar to the one from VC:
it seems easiest to add the calling convention right after the word function and before the return type, like
If we believe there is value in matching what VC has done we can do that too. But it seems if the compilers differ by how they emit (i.e. with or without mod opts) then maybe that's a red herring. FWIW, I think the scenarios where someone needs to consume them between C++ and C# are low, given that the support for C++/CLI is fairly limited these days. However, there is value in having a well-defined (and unique) format within the C# ecosystem itself. |
The documentation comment ID format for function pointers doesn't seem to be defined. Consider the following code (using recent daily build of Roslyn):
This prints:
which shows empty string as the documentation comment ID for a function pointer parameter.
The function pointers proposal doesn't define this format either.
How should the documentation comment ID format for function pointers look like? Once that's decided, the implementation should be updated so that documentation comment IDs for members with function pointers start working.
Originally reported at dotnet/csharplang#3978.
The text was updated successfully, but these errors were encountered: