Tracking issue for the thiscall calling convention

[froydnj]

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.

[ids1024]

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]

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]

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

[steveklabnik]

Triage: not aware of any movement on stabilizing this.

[whatisaphone]

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]

What's blocking stabilization of this?

[pravic]

The same question.

cc @dtolnay to route this to an appropriate person.

[super-continent]

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

[zorftw]

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

[chorman0773]

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]

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]

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]

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]

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

[petrochenkov]

@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]

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.

[nagisa]

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)

[Trolldemorted]

Should we @ them directly, or will they notice because it is now tagged T-lang?

[compiler-errors]

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.

[joshtriplett]

@rfcbot poll T-lang Should we stabilize thiscall?

[rfcbot]

Team member @joshtriplett has asked teams: T-lang, for consensus on:

Should we stabilize thiscall?

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

[nikomatsakis]

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

[compiler-errors]

canceling fcp in favor of poll above

@rfcbot fcp cancel

[compiler-errors]

@rfcbot cancel

[rfcbot]

@compiler-errors proposal cancelled.

[joshtriplett]

(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]

I interpreted:

1. the reassignment of team tag to T-lang by @nagisa
2. @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.