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 |
Mark-Simulacrum
added
B-unstable
Mark-Simulacrum
added
the
C-tracking-issue
|
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 |
|
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. |
compiler-errors
added
the
I-lang-nominated
|
@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. |
joshtriplett
removed
the
I-lang-nominated
|
canceling fcp in favor of poll above @rfcbot fcp cancel |
compiler-errors
added
T-compiler
|
@rfcbot cancel |
|
@compiler-errors proposal cancelled. |
rfcbot
removed
proposed-final-comment-period
compiler-errors
added
T-lang
|
(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.
Each `bindgen` release may upgrade the list of Rust targets. For instance,
currently, in their master branch [1], the latest ones are:
Nightly => {
vectorcall_abi: #124485,
ptr_metadata: #81513,
layout_for_ptr: #69835,
},
Stable_1_77(77) => { offset_of: #106655 },
Stable_1_73(73) => { thiscall_abi: #42202 },
Stable_1_71(71) => { c_unwind_abi: #106075 },
Stable_1_68(68) => { abi_efiapi: #105795 },
By default, the highest stable release in their list is used, and users
are expected to set one if they need to support older Rust versions
(e.g. see [2]).
Thus, over time, new Rust features are used by default, and at some
point, it is likely that `bindgen` will emit Rust code that requires a
Rust version higher than our minimum (or perhaps enabling an unstable
feature). Currently, there is no problem because the maximum they have,
as seen above, is Rust 1.77.0, and our current minimum is Rust 1.78.0.
Therefore, set a Rust target explicitly now to prevent going forward in
time too much and thus getting potential build failures at some point.
Since we also support a minimum `bindgen` version, and since `bindgen`
does not support passing unknown Rust target versions, we need to use
the list of our minimum `bindgen` version, rather than the latest. So,
since `bindgen` 0.65.1 had this list [3], we need to use Rust 1.68.0:
/// Rust stable 1.64
/// * `core_ffi_c` ([Tracking issue](rust-lang/rust#94501))
=> Stable_1_64 => 1.64;
/// Rust stable 1.68
/// * `abi_efiapi` calling convention ([Tracking issue](rust-lang/rust#65815))
=> Stable_1_68 => 1.68;
/// Nightly rust
/// * `thiscall` calling convention ([Tracking issue](rust-lang/rust#42202))
/// * `vectorcall` calling convention (no tracking issue)
/// * `c_unwind` calling convention ([Tracking issue](rust-lang/rust#74990))
=> Nightly => nightly;
...
/// Latest stable release of Rust
pub const LATEST_STABLE_RUST: RustTarget = RustTarget::Stable_1_68;
Thus add the `--rust-target 1.68` parameter. Add a comment as well
explaining this.
An alternative would be to use the currently running (i.e. actual) `rustc`
and `bindgen` versions to pick a "better" Rust target version. However,
that would introduce more moving parts depending on the user setup and
is also more complex to implement.
Cc: Christian Poveda <[email protected]>
Cc: Emilio Cobos Álvarez <[email protected]>
Link: https://github.com/rust-lang/rust-bindgen/blob/21c60f473f4e824d4aa9b2b508056320d474b110/bindgen/features.rs#L97-L105 [1]
Link: rust-lang/rust-bindgen#2960 [2]
Link: https://github.com/rust-lang/rust-bindgen/blob/7d243056d335fdc4537f7bca73c06d01aae24ddc/bindgen/features.rs#L131-L150 [3]
Signed-off-by: Miguel Ojeda <[email protected]>
Each `bindgen` release may upgrade the list of Rust targets. For instance,
currently, in their master branch [1], the latest ones are:
Nightly => {
vectorcall_abi: #124485,
ptr_metadata: #81513,
layout_for_ptr: #69835,
},
Stable_1_77(77) => { offset_of: #106655 },
Stable_1_73(73) => { thiscall_abi: #42202 },
Stable_1_71(71) => { c_unwind_abi: #106075 },
Stable_1_68(68) => { abi_efiapi: #105795 },
By default, the highest stable release in their list is used, and users
are expected to set one if they need to support older Rust versions
(e.g. see [2]).
Thus, over time, new Rust features are used by default, and at some
point, it is likely that `bindgen` will emit Rust code that requires a
Rust version higher than our minimum (or perhaps enabling an unstable
feature). Currently, there is no problem because the maximum they have,
as seen above, is Rust 1.77.0, and our current minimum is Rust 1.78.0.
Therefore, set a Rust target explicitly now to prevent going forward in
time too much and thus getting potential build failures at some point.
Since we also support a minimum `bindgen` version, and since `bindgen`
does not support passing unknown Rust target versions, we need to use
the list of our minimum `bindgen` version, rather than the latest. So,
since `bindgen` 0.65.1 had this list [3], we need to use Rust 1.68.0:
/// Rust stable 1.64
/// * `core_ffi_c` ([Tracking issue](rust-lang/rust#94501))
=> Stable_1_64 => 1.64;
/// Rust stable 1.68
/// * `abi_efiapi` calling convention ([Tracking issue](rust-lang/rust#65815))
=> Stable_1_68 => 1.68;
/// Nightly rust
/// * `thiscall` calling convention ([Tracking issue](rust-lang/rust#42202))
/// * `vectorcall` calling convention (no tracking issue)
/// * `c_unwind` calling convention ([Tracking issue](rust-lang/rust#74990))
=> Nightly => nightly;
...
/// Latest stable release of Rust
pub const LATEST_STABLE_RUST: RustTarget = RustTarget::Stable_1_68;
Thus add the `--rust-target 1.68` parameter. Add a comment as well
explaining this.
An alternative would be to use the currently running (i.e. actual) `rustc`
and `bindgen` versions to pick a "better" Rust target version. However,
that would introduce more moving parts depending on the user setup and
is also more complex to implement.
Cc: Christian Poveda <[email protected]>
Cc: Emilio Cobos Álvarez <[email protected]>
Link: https://github.com/rust-lang/rust-bindgen/blob/21c60f473f4e824d4aa9b2b508056320d474b110/bindgen/features.rs#L97-L105 [1]
Link: rust-lang/rust-bindgen#2960 [2]
Link: https://github.com/rust-lang/rust-bindgen/blob/7d243056d335fdc4537f7bca73c06d01aae24ddc/bindgen/features.rs#L131-L150 [3]
Signed-off-by: Miguel Ojeda <[email protected]>
Each `bindgen` release may upgrade the list of Rust targets. For instance,
currently, in their master branch [1], the latest ones are:
Nightly => {
vectorcall_abi: #124485,
ptr_metadata: #81513,
layout_for_ptr: #69835,
},
Stable_1_77(77) => { offset_of: #106655 },
Stable_1_73(73) => { thiscall_abi: #42202 },
Stable_1_71(71) => { c_unwind_abi: #106075 },
Stable_1_68(68) => { abi_efiapi: #105795 },
By default, the highest stable release in their list is used, and users
are expected to set one if they need to support older Rust versions
(e.g. see [2]).
Thus, over time, new Rust features are used by default, and at some
point, it is likely that `bindgen` will emit Rust code that requires a
Rust version higher than our minimum (or perhaps enabling an unstable
feature). Currently, there is no problem because the maximum they have,
as seen above, is Rust 1.77.0, and our current minimum is Rust 1.78.0.
Therefore, set a Rust target explicitly now to prevent going forward in
time too much and thus getting potential build failures at some point.
Since we also support a minimum `bindgen` version, and since `bindgen`
does not support passing unknown Rust target versions, we need to use
the list of our minimum `bindgen` version, rather than the latest. So,
since `bindgen` 0.65.1 had this list [3], we need to use Rust 1.68.0:
/// Rust stable 1.64
/// * `core_ffi_c` ([Tracking issue](rust-lang/rust#94501))
=> Stable_1_64 => 1.64;
/// Rust stable 1.68
/// * `abi_efiapi` calling convention ([Tracking issue](rust-lang/rust#65815))
=> Stable_1_68 => 1.68;
/// Nightly rust
/// * `thiscall` calling convention ([Tracking issue](rust-lang/rust#42202))
/// * `vectorcall` calling convention (no tracking issue)
/// * `c_unwind` calling convention ([Tracking issue](rust-lang/rust#74990))
=> Nightly => nightly;
...
/// Latest stable release of Rust
pub const LATEST_STABLE_RUST: RustTarget = RustTarget::Stable_1_68;
Thus add the `--rust-target 1.68` parameter. Add a comment as well
explaining this.
An alternative would be to use the currently running (i.e. actual) `rustc`
and `bindgen` versions to pick a "better" Rust target version. However,
that would introduce more moving parts depending on the user setup and
is also more complex to implement.
Starting with `bindgen` 0.71.0 [4], we will be able to set any future
Rust version instead, i.e. we will be able to set here our minimum
supported Rust version. Christian implemented it [5] after seeing this
patch. Thanks!
Cc: [email protected] # 6.12.y only (since older LTSs only support a single `bindgen` version)
Cc: Christian Poveda <[email protected]>
Cc: Emilio Cobos Álvarez <[email protected]>
Link: https://github.com/rust-lang/rust-bindgen/blob/21c60f473f4e824d4aa9b2b508056320d474b110/bindgen/features.rs#L97-L105 [1]
Link: rust-lang/rust-bindgen#2960 [2]
Link: https://github.com/rust-lang/rust-bindgen/blob/7d243056d335fdc4537f7bca73c06d01aae24ddc/bindgen/features.rs#L131-L150 [3]
Link: https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md#0710-2024-12-06 [4]
Link: rust-lang/rust-bindgen#2993 [5]
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
Each `bindgen` release may upgrade the list of Rust targets. For instance,
currently, in their master branch [1], the latest ones are:
Nightly => {
vectorcall_abi: #124485,
ptr_metadata: #81513,
layout_for_ptr: #69835,
},
Stable_1_77(77) => { offset_of: #106655 },
Stable_1_73(73) => { thiscall_abi: #42202 },
Stable_1_71(71) => { c_unwind_abi: #106075 },
Stable_1_68(68) => { abi_efiapi: #105795 },
By default, the highest stable release in their list is used, and users
are expected to set one if they need to support older Rust versions
(e.g. see [2]).
Thus, over time, new Rust features are used by default, and at some
point, it is likely that `bindgen` will emit Rust code that requires a
Rust version higher than our minimum (or perhaps enabling an unstable
feature). Currently, there is no problem because the maximum they have,
as seen above, is Rust 1.77.0, and our current minimum is Rust 1.78.0.
Therefore, set a Rust target explicitly now to prevent going forward in
time too much and thus getting potential build failures at some point.
Since we also support a minimum `bindgen` version, and since `bindgen`
does not support passing unknown Rust target versions, we need to use
the list of our minimum `bindgen` version, rather than the latest. So,
since `bindgen` 0.65.1 had this list [3], we need to use Rust 1.68.0:
/// Rust stable 1.64
/// * `core_ffi_c` ([Tracking issue](rust-lang/rust#94501))
=> Stable_1_64 => 1.64;
/// Rust stable 1.68
/// * `abi_efiapi` calling convention ([Tracking issue](rust-lang/rust#65815))
=> Stable_1_68 => 1.68;
/// Nightly rust
/// * `thiscall` calling convention ([Tracking issue](rust-lang/rust#42202))
/// * `vectorcall` calling convention (no tracking issue)
/// * `c_unwind` calling convention ([Tracking issue](rust-lang/rust#74990))
=> Nightly => nightly;
...
/// Latest stable release of Rust
pub const LATEST_STABLE_RUST: RustTarget = RustTarget::Stable_1_68;
Thus add the `--rust-target 1.68` parameter. Add a comment as well
explaining this.
An alternative would be to use the currently running (i.e. actual) `rustc`
and `bindgen` versions to pick a "better" Rust target version. However,
that would introduce more moving parts depending on the user setup and
is also more complex to implement.
Starting with `bindgen` 0.71.0 [4], we will be able to set any future
Rust version instead, i.e. we will be able to set here our minimum
supported Rust version. Christian implemented it [5] after seeing this
patch. Thanks!
Cc: Christian Poveda <[email protected]>
Cc: Emilio Cobos Álvarez <[email protected]>
Cc: [email protected] # needed for 6.12.y; unneeded for 6.6.y; do not apply to 6.1.y
Fixes: c844fa6 ("rust: start supporting several `bindgen` versions")
Link: https://github.com/rust-lang/rust-bindgen/blob/21c60f473f4e824d4aa9b2b508056320d474b110/bindgen/features.rs#L97-L105 [1]
Link: rust-lang/rust-bindgen#2960 [2]
Link: https://github.com/rust-lang/rust-bindgen/blob/7d243056d335fdc4537f7bca73c06d01aae24ddc/bindgen/features.rs#L131-L150 [3]
Link: https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md#0710-2024-12-06 [4]
Link: rust-lang/rust-bindgen#2993 [5]
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
and others
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.
thiscallis 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: