-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Tracking issue for the thiscall
calling convention
#42202
Comments
If this doesn't exist, perhaps it warrants an RFC? In particular some kind of attribute to specify the symbol name as an alternative to |
I think this sounds like an excellent idea! |
It looks like there's already an |
Triage: not aware of any movement on stabilizing this. |
I see what you did there, and I like it. More seriously, I'm just swinging by to say I use this feature independently of bindgen, and I hope it's stabilized one day (or at least sticks around in some form) |
What's blocking stabilization of this? |
The same question. cc @dtolnay to route this to an appropriate person. |
Wondering the same myself, any updates on stabilizing this? Would be very nice to have access to in stable. |
It's been rather long, why is still unstable? |
Indeed. I have a use for this in my compiler project https://github.com/LightningCreations/lccc, which would allow me to write bindings to the C++ api in rust on MSVC (which I am able to do on other major compilers, but need thiscall for i386 windows). |
I think this feature should be stabilized. Stabilization ReportSummaryThe TestsThis feature is tested in Documentation PRs
|
If/when this is fcp'd, would anyone be ready with the stabilization PR? @drmeepster maybe? Not that I want to rush anyone. I understand people have other priorities and commitments, etc. But I am quite keen to see this stabilized as soon as realistically possible. 😀 |
The |
@petrochenkov Sorry, I'm a bit confused. Shouldn't it be treated the same as |
@ChrisDenton |
So I thought a bit more about the bindgen use case. Perhaps it would be more convenient to have a generic ABI similary to Anyway, it's all compatible with the strict version implemented in #90241 that supports |
Yeah, this definitely sounds like a T-lang question than a T-compiler one. What would be in scope of the T-compiler here is an advice to T-lang on the implementation quality of this ABI (which is no better or worse than the other stable ABI options people can pick from today.) (I’ll still leave it up to somebody from T-lang to cancel this FCP and start a new one for themselves) |
Should we @ them directly, or will they notice because it is now tagged T-lang? |
I don't think T-lang can cancel an FCP that they're not participating. I can nominate it and cc @rust-lang/lang. Happy to cancel the FCP in favor if they feel like it's necessary. |
@rfcbot poll T-lang Should we stabilize thiscall? |
Team member @joshtriplett has asked teams: T-lang, for consensus on:
|
Discussed in meeting. We are generally in favor of this. To avoid procedural pain we decided to just use rfcbot poll. |
canceling fcp in favor of poll above @rfcbot fcp cancel |
@rfcbot cancel |
@compiler-errors proposal cancelled. |
(The T-lang poll was meant to substitute for T-lang's inclusion in a multi-team FCP. I hope this wasn't taken as a substitute for making sure T-compiler was fine with this too.) |
I interpreted:
as saying "T-lang's decision, not ours". At this point, if any @rust-lang/compiler team member thinks that we should have continued with that FCP, they should speak up, since we'll have to do a retroactive FCP at this point (and/or unland that PR). I personally think that an FCP is unnecessary from our side, though. |
stabilize abi_thiscall Closes rust-lang/rust#42202, stabilizing the use of the "thiscall" ABI. FCP was substituted by a poll, and the poll has been accepted.
stabilize abi_thiscall Closes rust-lang/rust#42202, stabilizing the use of the "thiscall" ABI. FCP was substituted by a poll, and the poll has been accepted.
stabilize abi_thiscall Closes rust-lang/rust#42202, stabilizing the use of the "thiscall" ABI. FCP was substituted by a poll, and the poll has been accepted.
stabilize abi_thiscall Closes rust-lang/rust#42202, stabilizing the use of the "thiscall" ABI. FCP was substituted by a poll, and the poll has been accepted.
stabilize abi_thiscall Closes rust-lang/rust#42202, stabilizing the use of the "thiscall" ABI. FCP was substituted by a poll, and the poll has been accepted.
Added in #42058, which fixes #42044 and related requests from other bugs.
This calling convention is the default calling convention for C++ instance methods in the (MSVC) Windows ABI. At the very least, bindgen (and its dependency syntex) need this to exist so they have a reasonable chance of representing C++ instance methods in an AST.
thiscall
is therefore important for the interop story between Rust and C++ on Windows.I don't think you could actually write callable C++ instance methods in Rust for MSVC, since mangled names in MSVC contain characters that, AFAICT, are not legal in Rust identifiers ('?', for instance). But maybe there is cleverness around assigning assembly names to things that I am not aware of.
The text was updated successfully, but these errors were encountered: