Undefined symbols for architecture x86_64 for previously compiled symbols

[znxftw]

When I tried the following sequence of incremental compilations :

fn main() {
    println!("{}", 1 - 2);
}

builds & runs fine (as expected).

Followed by changing the statement to :

println!("{}", 1u32 - 2);

build fails (as expected) with attempt to compute 1_u32 - 2_u32, which would overflow.

Then changing the statement back to

println!("{}", 1 - 2);

build succeeds (as expected) but run panics (unexpected) with thread 'main' panicked at 'attempt to subtract with overflow', src/main.rs:2:20. It's still inferring it to be an unsigned.

If I now change it into

println!("{}", 1i32 - 2);

build fails (unexpected) with the following error :

  = note: Undefined symbols for architecture x86_64:
            "core::fmt::ArgumentV1::new_display::h04b0a7b0eb5c5251", referenced from:
                playground::main::h42d87684ccf792ed in playground-5cdb2e37b25b0f71.272flcw1p2i5zhh8.rcgu.o
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

Any subsequent builds with i32 or without an explicit type fails with the same error.

Some other notes :

• cargo clean & then running fixes it.
• changing to a differently sized integer seems to fix it.
• directly starting with u32 (ignoring first step above) wasn't causing panic or error
• this was not replicable on opt-level = 3 (and different behaviour in other opt-levels)
• attaching os related info in meta as I'm not sure if it's replicable across all systems

Meta

rustc --version --verbose:

rustc 1.68.2 (9eb3afe9e 2023-03-27)
binary: rustc
commit-hash: 9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0
commit-date: 2023-03-27
host: x86_64-apple-darwin
release: 1.68.2
LLVM version: 15.0.6

OS : macOS Ventura Version 13.3.1 (22E261)
xcode-tools : 14.3.0.0.1.1679647830

Backtrace

stack backtrace:
   0: rust_begin_unwind
             at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/panicking.rs:64:14
   2: core::panicking::panic
             at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/panicking.rs:114:5
   3: playground::main
             at ./src/main.rs:2:20
   4: core::ops::function::FnOnce::call_once
             at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/ops/function.rs:250:5

for the initial panic

[jyn514]

I'm going to mark this as unsound since the panic in the third code snippet looks like a miscompilation.

[ehuss]

Thanks for the detailed report! I believe this is a duplicate of #108216, so closing in favor of that. When the build fails, rustc has left the incremental cache in an invalid state.