I compiled this code with -C opt-level=3:

#![feature(optimize_attribute)]

#[optimize(none)]
pub fn foo() {
    let _x = 123;
}

#[no_mangle]
pub fn bar() {
    foo();
}

I expected the assembly to either contain the number 123 somewhere, or produce a warning or error. Instead, I got this assembly:

bar:
        ret

Godbolt link

Adding #[inline(never)] to foo() gives the expected behavior. Godbolt link

example::foo::h70a9b33d354cf334:
        mov     dword ptr [rsp - 4], 123
        ret

bar:
        jmp     qword ptr [rip + example::foo::h70a9b33d354cf334@GOTPCREL]

The #[optimize(none)] attribute was recently added in #128657. And according to the discussion in the tracking issue at #54882, it seems like the main motivation of #[optimize(none)] is for debugging.

In this case, it seems like the compiler is inlining foo() into bar() and then proceeding to optimize bar(). This seems counterproductive for debugging. Therefore, I think that #[optimize(none)] should imply #[inline(never)]. Or if that is "too magic", then the compiler should at least produce a warning or error.

Meta

Reproduces on godbolt with rustc 1.86.0-nightly (ae5de6c75 2025-01-29)