mirror of
https://github.com/rust-lang/rust.git
synced 2025-11-24 08:37:03 +00:00
35a82b8dde
error when ABI does not support guaranteed tail calls Some ABIs cannot support guaranteed tail calls. There isn't really an exhaustive list, so this is a best effort. Conveniently, we already disallow calling most of these directly anyway. The only exception that I was able to trigger an LLVM assertion with so far was `cmse-nonsecure-entry`. For that calling convention, LLVM specifically notes that (guaranteed) tail calls cannot be supported:28dbbba6c3/llvm/lib/Target/ARM/ARMISelLowering.cpp (L2331-L2335)--- I have some doubts about the implementation here though. I think it would be nicer to use `CanonAbi`, and move the `become` ABI check into `rustc_hir_typeck`, similar to `check_call_abi`:d6deffe2de/compiler/rustc_hir_typeck/src/callee.rs (L157-L194)Both the check for whether an ABI is callable and whether it supports guaranteed tail calls can then be methods (containing exhaustive matches) on `CanonAbi`. I'm however not sure - if the ABI checks are deliberately only performed when constructing MIR - what assumptions can be made about the `call` expression in [`check_expr_become`](d6deffe2de/compiler/rustc_hir_typeck/src/expr.rs (L1126-L1150)), it looks like currently the check that the "argument" to `become` is a function call also only occurs later during MIR construction Are there issues with validating the ABI earlier in `rustc_hir_typeck` that I'm overlooking? I believe that we should already know the call's ABI and whether it is c-variadic at that point. cc ````@workingjubilee```` for `CanonAbi`, ````@davidtwco```` for cmse r? ````@WaffleLapkin````