This is similar to #118393. If someone figures out how to do one it should be easy to do the other as well.
For a long time, panics from compiler_builtins would result in linker errors unless they happened to be optimized out by the linker before resolution. Since #122580, such calls will either be replaced by a backend's abort intrinsic or a compile error during code generation.
I've used this locally to assess whether the PR fixes the root problem:
RUSTFLAGS="-Copt-level=1 -Cdebug-assertions=yes" cargo +nightly build -Zbuild-std --target=x86_64-unknown-linux-gnu
objdump -r target/x86_64-unknown-linux-gnu/debug/deps/libcompiler_builtins-b10ebdb7a18763a9.rlib | grep core
This objdump -r | grep is searching for mentions of core in the relocations inside the rlib. If don't find any, then compiler_builtins does not depend on core at link-time. There may be a more fine-tuned way to write this check that would make a test more robust, but this grep is sufficient to validate the property we need.
This is similar to #118393. If someone figures out how to do one it should be easy to do the other as well.
For a long time, panics from
compiler_builtinswould result in linker errors unless they happened to be optimized out by the linker before resolution. Since #122580, such calls will either be replaced by a backend's abort intrinsic or a compile error during code generation.I've used this locally to assess whether the PR fixes the root problem:
This
objdump -r | grepis searching for mentions ofcorein the relocations inside the rlib. If don't find any, thencompiler_builtinsdoes not depend oncoreat link-time. There may be a more fine-tuned way to write this check that would make a test more robust, but this grep is sufficient to validate the property we need.