Repository navigation
Functions are missing from "--emit=llvm-ir" and "--emit=asm" #119850
Description
Ever since #116505 landed, functions can be missing from "--emit=llvm-ir" and "--emit=asm" unless they are declared with #[inline(never)] or #[no_mangle]. This is quite surprising to most people that want to explore the LLVM IR / asm of a Rust function.
It's unclear how to best fix this, since not producing LLVM IR or asm (but only MIR) when compiling these functions was part of the goal of #116505. Maybe these --emit flags should themselves cause the functions to be monomorphized so they become visible again?
Reacted by clubby789, Suraj, Sadiinso, Merlin04 and teor
Activity
compiler-errors commentedon Jan 11, 2024
I think this is reasonable and probably the best way to fix it.
briansmith commentedon Jan 12, 2024
There are some use cases where it would be better for a crate to be able to switch back to opt-in inlining. For example, if an application is compiling crates to dylibs they may be doing so so that they can replace a single dynamic library with a bug fix, without having to ship an update to the entire app. In this case they'd like very few functions inlined. It is error-prone to add
#[inline(never)]to each public item and also impossible with#[derive].With this in mind, instead of special casing these
--emitflags, I think it would be better to have a separate mechanism to switch to "opt in to inlining" behavior, perhaps which the--emitflags automatically trigger.Note that I realize that the compiler never made any guarantees about inlining, so what I'm asking for is actually an improvement over even the previous state of things, before automatic inlining was implemented. I do think automatic inlining by default was a good change.
RalfJung commentedon Jan 12, 2024
To replace a function you'll have to annotate it with
#[no_mangle]anyway I think; functions without any such attribute are assumed to be fully under rustc control.#[no_mangle]already disables automatic inlining.briansmith commentedon Jan 12, 2024
Ideally we'd be able to recompile a dylib crate with the same toolchain and have the resulting shared library be a drop-in replacement (ABI-compatible) for the previous one, as long as we don't change the public API of the crate in any way, at least if we use
-C symbol-mangling-version=v0.Add note to Rust example explaining why functions are missing in the …
Add note to Rust example explaining why functions are missing in the …
Add note to Rust example explaining why functions are missing in the …
Mark start_main as inline(never)