-Zbuild-std shouldn't explode on compiler-builtins fragility

[0xdeafbeef]

I tried this code:

 rustup install nightly
 rustup component add rust-src --toolchain nightly-x86_64-unknown-linux-gnu
 cd $(mktemp -d) && cargo new aaaa && cd aaaa
RUSTFLAGS="-Clink-dead-code" "cargo" "build"   "--target" "x86_64-unknown-linux-gnu" "--release" "--config" "profile.release.debug=true" "-Z" "build-std"

get this error:

   Compiling compiler_builtins v0.1.146
   Compiling alloc v0.0.0 (/home/odm3n/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc)
   Compiling cfg-if v1.0.0
   Compiling adler2 v2.0.0
   Compiling memchr v2.7.4
   Compiling rustc-demangle v0.1.24
   Compiling unwind v0.0.0 (/home/odm3n/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/unwind)
error: `compiler_builtins` cannot call functions through upstream monomorphizations; encountered invalid call from `<int::big::u256 as rustc_std_workspace_core::fmt::Debug>::fmt` to `rustc_std_workspace_core::fmt::Formatter::<'a>::debug_tuple_field1_finish`

error: `compiler_builtins` cannot call functions through upstream monomorphizations; encountered invalid call from `<int::big::i256 as rustc_std_workspace_core::fmt::Debug>::fmt` to `rustc_std_workspace_core::fmt::Formatter::<'a>::debug_tuple_field1_finish`

error: could not compile `compiler_builtins` (lib) due to 2 previous errors

Meta

rustc --version --verbose:

rustc 1.87.0-nightly (ce36a966c 2025-02-17)
binary: rustc
commit-hash: ce36a966c79e109dabeef7a47fe68e5294c6d71e
commit-date: 2025-02-17
host: x86_64-unknown-linux-gnu
release: 1.87.0-nightly
LLVM version: 20.1.0

[0xdeafbeef]

Compiles with nightly-2023-01-21, so it's a regression

[0xdeafbeef]

searched toolchains nightly-2023-01-21 through nightly-2025-01-01

---

Regression in nightly-2024-07-30

---

fetching https://static.rust-lang.org/dist/2024-07-29/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2024-07-29: 40 B / 40 B [=======================================================================] 100.00 % 1.49 MB/s converted 2024-07-29 to 2cbbe8b
fetching https://static.rust-lang.org/dist/2024-07-30/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2024-07-30: 40 B / 40 B [=======================================================================] 100.00 % 1.40 MB/s converted 2024-07-30 to 612a33f
looking for regression commit between 2024-07-29 and 2024-07-30
fetching (via remote github) commits from max(2cbbe8b, 2024-07-27) to 612a33f
ending github query because we found starting sha: 2cbbe8b
get_commits_between returning commits, len: 8
commit[0] 2024-07-28: Auto merge of #128313 - GuillaumeGomez:rollup-kacb489, r=GuillaumeGomez
commit[1] 2024-07-29: Auto merge of #125443 - nnethercote:rustfmt-use-decls, r=lcnr,cuviper,GuillaumeGomez
commit[2] 2024-07-29: Auto merge of #128330 - matthiaskrgr:rollup-auairjd, r=matthiaskrgr
commit[3] 2024-07-29: Auto merge of #125016 - nicholasbishop:bishop-cb-112, r=tgross35
commit[4] 2024-07-29: Auto merge of #128334 - matthiaskrgr:rollup-nhxdt0c, r=matthiaskrgr
commit[5] 2024-07-29: Auto merge of #128265 - DianQK:instsimplify-before-inline, r=saethlin
commit[6] 2024-07-29: Auto merge of #128112 - Oneirical:testidigitation-cantrip, r=jieyouxu
commit[7] 2024-07-29: Auto merge of #128350 - matthiaskrgr:rollup-bcuhts8, r=matthiaskrgr
ERROR: no CI builds available between 2cbbe8b and 612a33f within last 167 days

[bjorn3]

cc @matthiaskrgr who might have opinions about -Clink-dead-code. In any case compiler-builtins has very strict requirements about how it must be built as it must not ever make a call into any other crate for any reason, so I don't think it is unexpected that -Clink-dead-code breaks it.

[saethlin]

-Clink-dead-code should have been called -Ztry-to-help-coverage-tools and never stabilized. It was ironically added to assist coverage tools that claim to not need compiler support, and has since grown to do a lot more than its original scope. Internally, it is basically a pile of hacks.

The flag ends up being somewhat useful in fuzzing the compiler because it means if your reducer or fuzzer doesn't really understand Rust and accidentally makes something unreachable, it (usually) gets compiled anyway. But that use case is fulfilled by -Zprint-mono-items=eager (which is also misnamed).

If we "correctly" handled -Clink-dead-code when building compiler-builtins, we would in some cases produce a library that is not linkable. @0xdeafbeef Can you explain why you want to use -Clink-dead-code with -Zbuild-std? Because probably the way to "fix" this situation is to add more special-casing of the compiler-builtins crate; making that flag not apply to it.

[0xdeafbeef]

-Clink-dead-code should have been called -Ztry-to-help-coverage-tools and never stabilized. It was ironically added to assist coverage tools that claim to not need compiler support, and has since grown to do a lot more than its original scope. Internally, it is basically a pile of hacks.

The flag ends up being somewhat useful in fuzzing the compiler because it means if your reducer or fuzzer doesn't really understand Rust and accidentally makes something unreachable, it (usually) gets compiled anyway. But that use case is fulfilled by -Zprint-mono-items=eager (which is also misnamed).

If we "correctly" handled -Clink-dead-code when building compiler-builtins, we would in some cases produce a library that is not linkable. @0xdeafbeef Can you explain why you want to use -Clink-dead-code with -Zbuild-std? Because probably the way to "fix" this situation is to add more special-casing of the compiler-builtins crate; making that flag not apply to it.

I just wanted to use

RUSTFLAGS='-Zextra-const-ub-checks -Zstrict-init-checks -Zforce-unstable-if-unmarked' cargo +nightly fuzz  --build-std  -s none

to fuzz my app with debug aserts in std without asan and got a million

cannot call functions through upstream monomorphizations

errors.

After an hour of debugging, i've found that -Clink-dead-code is the cause of the error. I'm not sure if it's needed, but it's enabled by default :)

rust-fuzz/cargo-fuzz#400

[workingjubilee]

@0xdeafbeef cargo-fuzz has stopped doing that by default, see rust-fuzz/cargo-fuzz#394

[workingjubilee]

We don't intend to fix this and cargo fuzz has published new releases.

[saethlin]

We don't intend to fix this

While it's true that OP should not expect any upcoming nightly or stable release to make the above workflow work again, I do think we need to do something about the fact that -Zbuild-std users frequently trip over the exotic requirements of compiler-builtins.

[workingjubilee]

Reasonable enough.