Tracking Issue for Explicit Tail Calls

[WaffleLapkin]

This is a tracking issue for the RFC "Explicit Tail Calls" (rust-lang/rfcs#3407) (note that RFC is not accepted yet, this feature is currently implemented as part of an experiment).
The feature gate for the issue is #![feature(explicit_tail_calls)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC
  • Parsing/HIR/MIR
  • Implement the necessary checks for tail calls
  • Add support in LLVM backend (draft commits: dee279d, 0722a1e)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

(fill when the rfc is merged)

Implementation history

• Syntactically accept become expressions (explicit tail calls experiment) #112790
• llvm ffi: Expose CallInst->setTailCallKind #112791
• hir: Add Become expression kind (explicit tail calls experiment) #112887
• thir: Add Become expression kind #113093
• Document become keyword #113095
• Support tail calls in mir via TerminatorKind::TailCall #113128
• implement checks for tail calls #133607
• fix tail call checks wrt #[track_caller] #135973
• Don't drop types with no drop glue when building drops for tailcalls #135976
• Implement support for become and explicit tail call codegen for the LLVM backend #144232

[scottmcm]

While looking at something else, I tried using tailcc, and got sad:

LLVM ERROR: Can't handle guaranteed tail call under win64 yet
error: could not compile `core` (lib)

[travis-leith]

@scottmcm can you clarify: is this issue (llvm/llvm-project#53271) holding up implemention of explicit tail calls in rust?

[WaffleLapkin]

@travis-leith this is not technically blocking the implementation, to my knowledge. But it is a big/noticeable problem for testing & stabilization.