Failure on subsequent builds when --emit asm used without -C save-temps.

[hydra]

I tried this code:

(see attached project)
buildfailure-1.zip

cargo build --bin=nucleof446re --target=thumbv7m-none-eabi --features="dep-stm32f446" -vv
...
cargo build --bin=nucleof446re --target=thumbv7m-none-eabi --features="dep-stm32f446" -vv

I expected to see this happen:

build the first time, build the second time.

Instead, this happened: explanation

On the first build, success.
On the second build

error: could not copy "D:\\Users\\Hydra\\Documents\\dev\\playground\\rust\\buildfailure-1\\crates\\boards\\target\\thumbv7m-none-eabi\\debug\\deps\\boards-381a71c28462db46.19nwjvde6m7mbrbk.rcgu.s" to "D:\\Users\\Hydra\\Documents\\dev\\playground\\rust\\buildfailure-1\\crates\\boards\\target\\thumbv7m-none-eabi\\debug\\deps\\boards-381a71c28462db46.s": The system cannot find the file specified. (os error 2)

See log (attached)

log.txt

Upon investigation it appears that the rustflags (in the cargo configuration) --emit asm cause the subsequent build failure, but only when -C save-temps is NOT used.

i.e:

savetemps	emit asm	result
disabled	disabled	success
enabled	disabled	success
disabled	enabled	failure
enabled	enabled	success

Meta

rustc --version --verbose:

rustc 1.57.0-nightly (5ecc8ad84 2021-09-19)
binary: rustc
commit-hash: 5ecc8ad8462574354a55162a0c16b10eb95e3e70
commit-date: 2021-09-19
host: x86_64-pc-windows-gnu
release: 1.57.0-nightly
LLVM version: 13.0.0

[bjorn3]

Does the same thing happen with CARGO_INCREMENTAL=0? It is possible that this is caused by the assembly file not being stored in the incremental cache, yet not regenerated due to the codegen unit dependencies still being fresh.

[hydra]

Just following up on this.

The problem still exists with the nightly I'm currently using:

rustc 1.64.0-nightly (1c7b36d4d 2022-07-12)
binary: rustc
commit-hash: 1c7b36d4db582cb47513a6c7176baaec1c3346ab
commit-date: 2022-07-12
host: x86_64-pc-windows-gnu
release: 1.64.0-nightly
LLVM version: 14.0.6

To replicate, extract the example project, comment out Line 22 in the crates/boards/cargo/config.toml as follows:

Original:

  "-C", "save-temps", # <-- when this is disabled, the subsequent build fails, but only when `--emit asm` is also enabled.

Commented out:

  #"-C", "save-temps", # <-- when this is disabled, the subsequent build fails, but only when `--emit asm` is also enabled.

Then run this command sequence:

cd crates/boards
cargo build --bin=nucleof446re --target=thumbv7em-none-eabihf --features="dep-stm32f446" -vv
cargo build --bin=nucleof446re --target=thumbv7em-none-eabihf --features="dep-stm32f446" -vv

Then observe the errors:

error: could not copy "D:\\Users\\Hydra\\Documents\\dev\\playground\\rust\\buildfailure-1\\crates\\boards\\target\\thumbv7em-none-eabihf\\debug\\deps\\boards-b22cf056f2c46d98.3dm2sxxyyyvowhj0.rcgu.s" to "D:\\Users\\Hydra\\Documents\\dev\\playground\\rust\\buildfailure-1\\crates\\boards\\target\\thumbv7em-none-eabihf\\debug\\deps\\boards-b22cf056f2c46d98.s": The system cannot find the file specified. (os error 2)

error: could not compile `boards` due to previous error

Running this command sequence, with the same cargo.toml with line 22 commented out results in success.

cd crates/boards
CARGO_INCREMENTAL=0 cargo build --bin=nucleof446re --target=thumbv7em-none-eabihf --features="dep-stm32f446" -vv
CARGO_INCREMENTAL=0 cargo build --bin=nucleof446re --target=thumbv7em-none-eabihf --features="dep-stm32f446" -vv

This indicates that there is an issue with cargo incremental builds right?

What happens next?

[hydra]

The problem still exists on a nightly from yesterday:

$ rustup default nightly-2023-02-14
...
$ rustup target add thumbv7m-none-eabi
$ rustup target add thumbv7em-none-eabihf
$ rustc --version --verbose
rustc 1.69.0-nightly (065852def 2023-02-13)
binary: rustc
commit-hash: 065852def0903296da33a9eaf557f230bcf3a61a
commit-date: 2023-02-13
host: x86_64-pc-windows-gnu
release: 1.69.0-nightly
LLVM version: 15.0.7

[pacak]

FWIW it's still broken in current nightly, I have a reproduction case with no external dependencies: a crate with this source

pub fn main() -> u32 {
    1
}

And this command: export RUSTC_OPTIONS=--emit=asm; rm -rf target ; cargo build ; touch src/lib.rs ; cargo build

Does the same thing happen with CARGO_INCREMENTAL=0?

No, disabling incremental compilation seem to fix the problem.

It is possible that this is caused by the assembly file not being stored in the incremental cache, yet not regenerated due to the codegen unit dependencies still being fresh.

As far as I can see there's no assembly files in the incremental cache. They should probably be saved if --emit is present so #122597 can produce the right values. Regenerating means codegen must run either way which defeats the purpose of the incremental cache. Reading though incremental compilation docs, trying to understand how it supposed to work.

[pacak]

https://internals.rust-lang.org/t/interaction-between-incremental-compilation-and-emit/20551

[hydra]

@pacak Great to see this fixed, thanks for the investigation and PR!