Inconsistent recursive fn call elimination

[Rudxain]

I tried this code:

#[inline(never)]
#[no_mangle]
const fn deep(n: usize) {
    match n {
        0 => (),
        _ => deep(n - 1),
    }
}

#[inline(always)]
const fn inf() -> ! {
    inf()
}

fn main() {
    deep(usize::MAX);
    println!("✅");
    inf();
}

I expected to see this happen: prints "✅" fast and successfully, then hangs in an infinite loop.

Instead, this happened: prints "✅" fast and panics with stderr:

   Compiling playground v0.0.1 (/playground)
    Finished `release` profile [optimized] target(s) in 0.38s
     Running `target/release/playground`

thread 'main' has overflowed its stack
fatal runtime error: stack overflow

It seems commenting-out the attributes is no-op here.

Meta

https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=ed0941cd328e49d8737fdff01cd4a4aa

rustc --version --verbose:

1.80.0-nightly

(2024-05-28 da159eb331b27df52818)

Backtrace

<no diff>

Apologies in advance, if this issue is a dupe. I tried my best to find similar ones

[workingjubilee]

This seems to be a duplicate of #102952 and many others like that one.

[Rudxain]

Weirdly enough, I tried this with #112788

#![feature(explicit_tail_calls)]
const fn inf() -> ! {
    become inf()
}

fn main() {
    inf();
}

It still overflows the stack! Even though the (unofficial) docs claim it must not.

I've been reading about the RFC, and it seems the syntax is the only thing that got implemented

[workingjubilee]

interesting.

[bjorn3]

The llvm ir correctly contains

; playground::inf
; Function Attrs: nofree noreturn nosync nounwind nonlazybind memory(none) uwtable
define internal fastcc void @_ZN10playground3inf17hbbe49911b1985149E() unnamed_addr #3 {
start:
; call playground::inf
  tail call fastcc void @_ZN10playground3inf17hbbe49911b1985149E() #7
  unreachable
}

[workingjubilee]

weird.

[dianqk]

In my view, the code behavior initially mentioned in the issue is reasonable. I want to know why you expect it won't overflow the stack, inline(always) doesn't guarantee that inline will definitely occur.

[bjorn3]

The behavior in #125698 (comment) is definitively wrong. It uses become which should force a tail call, yet doesn't get tail called.

[the8472]

The tail call feature (#112788) is still in progress, e.g. #113128 has not been merged yet.

[Rudxain]

why you expect it won't overflow the stack

What I actually find surprising is that the compiler was eager to obliterate deep(usize::MAX) as if it was never there, but inf() didn't get the same similar treatment.

inline(always) doesn't guarantee that inline will definitely occur.

I know, I just wanted to "add emphasis" (I'm unsure if this is the correct terminology?)