Tracking issue for the `thiscall` calling convention #42202

froydnj · 2017-05-24T20:35:40Z

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:

ids1024 · 2017-05-25T01:11:23Z

But maybe there is cleverness around assigning assembly names to things that I am not aware of.

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 no_mangle.

froydnj · 2017-05-25T01:16:17Z

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 no_mangle.

I think this sounds like an excellent idea!

ids1024 · 2017-05-25T04:56:09Z

It looks like there's already an export_name attribute that does this. That probably would work.

steveklabnik · 2019-03-12T17:49:53Z

Triage: not aware of any movement on stabilizing this.

whatisaphone · 2019-04-25T15:24:56Z

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)

MSxDOS · 2020-09-28T20:22:02Z

What's blocking stabilization of this?

pravic · 2020-12-24T09:48:18Z

The same question.

cc @dtolnay to route this to an appropriate person.

super-continent · 2021-04-19T19:48:32Z

Wondering the same myself, any updates on stabilizing this? Would be very nice to have access to in stable.

zorftw · 2021-07-26T20:20:54Z

It's been rather long, why is still unstable?

chorman0773 · 2021-08-22T22:55:31Z

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).

beepster4096 · 2021-09-20T05:51:27Z

I think this feature should be stabilized.

Stabilization Report

Summary

The abi_thiscall feature allows code to export and link to functions with the thiscall abi. This is the abi used by default for C++ member functions on x86 MSVC, and is very important for C++ FFI.

Tests

This feature is tested in ui/extern/extern-thiscall.rs

Documentation PRs

The Reference: Document thiscall abi reference#1092
The Nomicon: Document thiscall abi nomicon#311
There are no known issues or unresolved questions related to this feature.

ChrisDenton · 2021-10-22T15:02:40Z

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. 😀

petrochenkov · 2021-10-23T14:25:55Z

The UNSUPPORTED_CALLING_CONVENTIONS lint needs to be turned into an error for thiscall before stabilization.
To do that support for Thiscall needs to be reduced to the self.arch == "x86" case in fn is_abi_supported.

ChrisDenton · 2021-10-23T19:36:18Z

@petrochenkov Sorry, I'm a bit confused. Shouldn't it be treated the same as Stdcall and Fastcall? They're already stabilized,

petrochenkov · 2021-10-23T19:57:49Z

@ChrisDenton
I think we should warn on the stable ones (#86231 (comment)), but for unstable conventions like thiscall we can proceed to immediately reporting an error instead.

petrochenkov · 2021-10-25T08:19:50Z

So I thought a bit more about the bindgen use case.
Suppose it wants to generate cross-platform bindings for a library with class methods, then it will need to emit thiscall ABI on x86 and C ABI everywhere else and put these two cases under cfgs.

Perhaps it would be more convenient to have a generic ABI similary to system (stdcall on x86, C elsewhere) that would expand to thiscall on x86 and to C everywhere else.
It may be a new separate ABI, but it could be more reasonable to not multiply entities, and make thiscall itself that generic ABI.

Anyway, it's all compatible with the strict version implemented in #90241 that supports thiscall only on x86.

nikomatsakis · 2023-07-18T19:00:00Z

Discussed in meeting. We are generally in favor of this. To avoid procedural pain we decided to just use rfcbot poll.

compiler-errors · 2023-08-07T17:06:04Z

canceling fcp in favor of poll above

@rfcbot fcp cancel

compiler-errors · 2023-08-07T17:07:10Z

@rfcbot cancel

rfcbot · 2023-08-07T17:07:11Z

@compiler-errors proposal cancelled.

joshtriplett · 2023-08-07T20:28:18Z

(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.)

compiler-errors · 2023-08-07T20:33:21Z

I interpreted:

the reassignment of team tag to T-lang by @nagisa
@oli-obk's r+ in stabilize abi_thiscall #114562

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.

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 <git@pvdrz.com> Cc: Emilio Cobos Álvarez <emilio@crisal.io> 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 <ojeda@kernel.org>

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: stable@vger.kernel.org # 6.12.y only (since older LTSs only support a single `bindgen` version) Cc: Christian Poveda <git@pvdrz.com> Cc: Emilio Cobos Álvarez <emilio@crisal.io> 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 <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241123180323.255997-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

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 <git@pvdrz.com> Cc: Emilio Cobos Álvarez <emilio@crisal.io> Cc: stable@vger.kernel.org # 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 <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241123180323.255997-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

commit 7a5f93e upstream. 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 <git@pvdrz.com> Cc: Emilio Cobos Álvarez <emilio@crisal.io> Cc: stable@vger.kernel.org # 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 <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241123180323.255997-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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 <git@pvdrz.com> Cc: Emilio Cobos Álvarez <emilio@crisal.io> Cc: stable@vger.kernel.org # 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 <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241123180323.255997-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

ids1024 mentioned this issue May 25, 2017

Add attribute to specify symbol name, as an alternative to no_mangle rust-lang/rfcs#2007

Closed

Mark-Simulacrum added B-unstable Blocker: Implemented in the nightly compiler and unstable. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 23, 2017

Mark-Simulacrum added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Jul 22, 2017

fitzgen mentioned this issue Jul 25, 2017

Tracking rustc bugs/features/RFCs that affect bindgen rust-lang/rust-bindgen#849

Open

10 tasks

karlhelgason mentioned this issue Aug 8, 2019

Custom auto rooter test crashes on windows 86 servo/rust-mozjs#462

Open

emilio mentioned this issue Mar 2, 2020

Missing class methods bindings when target is i686-pc-windows-gnu rust-lang/rust-bindgen#1739

Open

pravic mentioned this issue Apr 30, 2020

Could not find "abi_thiscall" nightly feature jplatte/caniuse.rs#6

Closed

rkr35 mentioned this issue Jun 24, 2020

Hook ProcessEvent rkr35/blps#5

Closed

piscisaureus mentioned this issue Aug 22, 2020

MSYS2 build failed: file too small to be an archive denoland/rusty_v8#426

Closed

pragmatrix mentioned this issue Jul 3, 2021

32bit binaries (at least windows) rust-skia/rust-skia#540

Closed

This was referenced Sep 19, 2021

Document thiscall abi rust-lang/reference#1092

Merged

Document thiscall abi rust-lang/nomicon#311

Merged

beepster4096 mentioned this issue Oct 24, 2021

Make thiscall abi on unsupported platforms a hard error #90241

Merged

joshtriplett removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Jul 25, 2023

Trolldemorted mentioned this issue Aug 6, 2023

stabilize abi_thiscall #114562

Merged

compiler-errors added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Aug 7, 2023

rfcbot removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Aug 7, 2023

compiler-errors added T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 7, 2023

bors closed this as completed in 06daa9e Aug 7, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for the `thiscall` calling convention #42202

Tracking issue for the `thiscall` calling convention #42202

froydnj commented May 24, 2017

ids1024 commented May 25, 2017

froydnj commented May 25, 2017

ids1024 commented May 25, 2017

steveklabnik commented Mar 12, 2019

whatisaphone commented Apr 25, 2019

MSxDOS commented Sep 28, 2020

pravic commented Dec 24, 2020

super-continent commented Apr 19, 2021

zorftw commented Jul 26, 2021

chorman0773 commented Aug 22, 2021

beepster4096 commented Sep 20, 2021

ChrisDenton commented Oct 22, 2021

petrochenkov commented Oct 23, 2021

ChrisDenton commented Oct 23, 2021

petrochenkov commented Oct 23, 2021

petrochenkov commented Oct 25, 2021

nikomatsakis commented Jul 18, 2023

compiler-errors commented Aug 7, 2023

compiler-errors commented Aug 7, 2023

rfcbot commented Aug 7, 2023

joshtriplett commented Aug 7, 2023

compiler-errors commented Aug 7, 2023 •

edited

Loading

Tracking issue for the thiscall calling convention #42202

Tracking issue for the thiscall calling convention #42202

Comments

froydnj commented May 24, 2017

ids1024 commented May 25, 2017

froydnj commented May 25, 2017

ids1024 commented May 25, 2017

steveklabnik commented Mar 12, 2019

whatisaphone commented Apr 25, 2019

MSxDOS commented Sep 28, 2020

pravic commented Dec 24, 2020

super-continent commented Apr 19, 2021

zorftw commented Jul 26, 2021

chorman0773 commented Aug 22, 2021

beepster4096 commented Sep 20, 2021

Stabilization Report

Summary

Tests

Documentation PRs

ChrisDenton commented Oct 22, 2021

petrochenkov commented Oct 23, 2021

ChrisDenton commented Oct 23, 2021

petrochenkov commented Oct 23, 2021

petrochenkov commented Oct 25, 2021

nikomatsakis commented Jul 18, 2023

compiler-errors commented Aug 7, 2023

compiler-errors commented Aug 7, 2023

rfcbot commented Aug 7, 2023

joshtriplett commented Aug 7, 2023

compiler-errors commented Aug 7, 2023 • edited Loading

Tracking issue for the `thiscall` calling convention #42202

Tracking issue for the `thiscall` calling convention #42202

compiler-errors commented Aug 7, 2023 •

edited

Loading