explicit_tail_calls: cannot `become` a function that never returns

[nagisa]

#![feature(explicit_tail_calls)]

fn foo() -> u64 {
    become std::process::abort()
}

currently says

error[E0308]: mismatched types
 --> src/lib.rs:4:5
  |
4 |     become std::process::abort()
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u64`, found `!`
  |
  = note: expected type `u64`
             found type `!`

While the RFC does require that the types match, ! sounds like it ought to be an exception to this rule: not returning at all is a perfectly valid thing to want to do when tail-calling and should not require any special handling other than in the type checking.

[hanna-kruppe]

Note that the RFC requires the entire signature to match (modulo lifetimes) so that caller and callee have the same ABI — that’s impler for backends, works with any calling convention, and matches Clang’s musttail. This applies equally to the return type, at least in cases where the non-! return type would lower to an out-pointer argument, since that also changes the ABI.

[nagisa]

Indeed. I might have been too hasty with "should not require any special handling" 😓. This limitation currently can be worked-around by constructing a wrapping function that then ultimately calls the -> ! function, i.e.

fn foo() -> u64 {
    become myabort();
}

#[inline(never)]
#[cold]
fn myabort() -> u64 {
    std::process::abort()
}

This feels ultimately like what rustc/backend could do for the user, but I could see it being low priority and not blocking F-explicit_tail_calls.

[WaffleLapkin]

@nagisa adding a wrapper defeats the purpose of tail calls, myabort will contain a normal call, at which point you could have just as well made it inside foo.

I'm gonna close this, since this is expected behavior and there isn't really anything to do here.