Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Support reading calling convention from modreq or modopt on the return type #34805

Closed
333fred opened this issue Apr 10, 2020 · 4 comments · Fixed by #39030
Closed

Support reading calling convention from modreq or modopt on the return type #34805

333fred opened this issue Apr 10, 2020 · 4 comments · Fixed by #39030
Labels
area-Interop-coreclr
Milestone
5.0.0

Comments

@333fred
Copy link
Member

333fred commented Apr 10, 2020

Runtime-side tracking of the extensible calling convention proposal. Compiler-side issue: dotnet/roslyn#39865. Will update with a final description of the actual spec when we've settled it.
@Dotnet-GitSync-Bot
Copy link
Collaborator

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Apr 10, 2020
@333fred 333fred mentioned this issue Apr 10, 2020
Closed
18 tasks
@jkotas jkotas added this to the 5.0 milestone Apr 10, 2020
@jeffschwMSFT
Copy link
Member

@AaronRobinsonMSFT

@AaronRobinsonMSFT AaronRobinsonMSFT removed the untriaged New issue has not been triaged by the area owner label Apr 10, 2020
@AaronRobinsonMSFT AaronRobinsonMSFT mentioned this issue Jun 19, 2020
Closed
@AaronRobinsonMSFT
Copy link
Member

AaronRobinsonMSFT commented Jun 19, 2020 •
edited
Loading

Based on plans in .NET 5, there are no current reasons to read any modopt values. This would change if/when we add CallConvSuppressGCTransition. Instead the goal here would be to ignore/block cases when we do discover an existing modopt that is attempting to change behavior. The goal here would be preventative for when we do add support in a future runtime.

@AaronRobinsonMSFT AaronRobinsonMSFT modified the milestones: 5.0.0, 6.0.0 Jun 24, 2020
@lambdageek lambdageek mentioned this issue Jun 29, 2020
Closed
7 tasks
@AaronRobinsonMSFT AaronRobinsonMSFT modified the milestones: 6.0.0, 5.0.0 Jul 6, 2020
@AaronRobinsonMSFT
Copy link
Member

Related #38133

lambdageek added a commit to lambdageek/mono that referenced this issue Jul 8, 2020
@lambdageek
[metadata] Initial support for MONO_CALL_UNMANAGED
8684def 
A MethodRefSig or a StandaloneSig can have the calling convention "unmanaged"
which is the default platform calling convention with optional modifiers
encoded in the modopts of the return type.

See dotnet/roslyn#39865 (comment)
and dotnet/runtime#34805

Contributes to dotnet/runtime#38480
@AaronRobinsonMSFT AaronRobinsonMSFT mentioned this issue Jul 8, 2020
Closed
@elinor-fung elinor-fung mentioned this issue Jul 15, 2020
Merged
@ghost ghost locked as resolved and limited conversation to collaborators Dec 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
area-Interop-coreclr
Projects
None yet
Milestone
5.0.0
Development

Successfully merging a pull request may close this issue.

Handle 'unmanaged' calling convention value elinor-fung/runtime
5 participants
@333fred @jkotas @jeffschwMSFT @AaronRobinsonMSFT @Dotnet-GitSync-Bot