-Clink-dead-code and -Cinstrument-coverage causes symbol already defined compiler error in nightly

[xd009642]

Code

With just the following cargo.toml

[package]
name = "debug-tarp-issue"
version = "0.1.0"
edition = "2018"

[dependencies]
reqwest = { version = "0.12", features = ["blocking"] }

and a main.rs with the default contents. Running

RUSTFLAGS="-Clink-dead-code -Cinstrument-coverage" cargo test

Results in:

error: symbol `_RNCNvNtNtNtNtCs6KohR1qTMkp_10hyper_util6client6legacy7connect4http7connect0Bb_` is already defined
   --> /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/hyper-util-0.1.10/src/client/legacy/connect/http.rs:795:8
    |
795 |     Ok(async move {
    |        ^^^^^^^^^^

error: could not compile `hyper-util` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
Error: Process completed with exit code 101.

I've done a bit of work to narrow this down. So either of the flags on their own is fine, it's just the combination that causes the issue.,

I also have a MRE reproduction repo here: https://github.com/xd009642/debug-tarp-issue

Version with regression

So because this happened in a CI job for tarpaulin and we have some flaky tests and I don't use a mac myself I don't have an exact version. But this first occurred in our CI January 13th 2025. This is evident because the mac nightly builds have failed from that date until now. Mac stable and beta still work fine.

[xd009642]

My end I'm also sorry I haven't investigated this sooner, I don't have a mac and there's an ever growing pile of issues so getting through things takes some concentrated effort my end

[Noratrieb]

Note that -Clink-dead-code is no longer useful for coverage and you can just remove it.

[xd009642]

hmm I've tried removing it in tarpaulin but then I get no coverage data in public modules with no tested code. But I can see cargo-llvm-cov gets me results without adding link-dead-code on the same files so I'll look into that 🤔

EDIT: silly me was doing overly constrained filtering of results

[apiraino]

I could compile the MRE reduction on x86_64 just to exclude it from the affected platforms

@rustbot label +O-macos

[saethlin]

Minimized further:

[package]
name = "scratch"
version = "0.1.0"
edition = "2024"

[dependencies]
tokio = { version = "1.43.0", features = ["net"] }

use std::future::Future;
use std::net::{Ipv4Addr, SocketAddr};
use tokio::net::{TcpStream};

async fn connect() {
    connect2().await;
}   

fn connect2() -> impl Future<Output = TcpStream> {
    let addr = SocketAddr::from(("127.0.0.1".parse::<Ipv4Addr>().unwrap(), 80));
    let connect = TcpStream::connect(addr);
    async move {
        connect.await.unwrap()
    }   
}

[saethlin]

The above reproducer is now portable. Still not minimal.

[saethlin]

This is also not a linkage issue, this is an issue in how eager monomorphization works

[saethlin]

Regression points to #135149 cc @compiler-errors
I was expecting this to bisect to your PR that made eager collection collect more things.

[compiler-errors]

lamo what

[saethlin]

We still get an error if you use -Zprint-mono-items=eager instead of -Clink-dead-code. Still haven't the foggiest idea why -Cinstrument-coverage matters, and I've tried using the trivial futures we provide in std::futures and those don't seem to trip this.

[compiler-errors]

Minimal, reproducible with -Zprint-mono-items=eager -Csymbol-mangling-version=v0.

fn opaque() -> impl Sized {}

fn test() -> impl FnOnce() {
    let opaque = opaque();
    move || {
        let opaque = opaque;
    }
}

fn main() {
    test()();
}

I'll put up a fix soon. Doesn't have to do with async/await (un)luckily.

Sorry for sniping the issue.

[apiraino]

thanks @saethlin and @compiler-errors ! :)