Regression: lto = true in build.rs causes cargo test --release --doc to fail to link
#8654
Comments
briansmith
changed the title
lto = true in build.rs cause cargo test --release --doc to fail to link on Windowslto = true in build.rs causes cargo test --release --doc to fail to link on Windows
briansmith
changed the title
lto = true in build.rs causes cargo test --release --doc to fail to link on Windowslto = true in build.rs causes cargo test --release --doc to fail to link
|
The same problem occurs on Linux too: |
|
Thanks for the report! It looks like Cargo needs to pass the I'll try to fix this soonish. |
ehuss
added
A-lto
|
This seems like a potential regression in rustdoc, regardless -- generally speaking since presumably rustdoc isn't actually using these codegen arguments we probably shouldn't behave differently in the presence of them? At the very least we need to include this in release notes. |
|
The issue is that Cargo is now building LTO dependencies with |
Fix LTO with doctests. This fixes an issue where `cargo test --release` would fail to run doctests if LTO is set in `profile.release` or `profile.bench`. The issue is that dependencies were built with `-Clinker-plugin-lto`, but the final rustdoc invocation did not issue `-C lto`. This causes a link failure (or crash!) because the necessary object code was missing. This is because rustdoc historically did not support codegen flags, so Cargo has never passed them in. Rustdoc now supports codegen flags (via rust-lang/rust#63827), so it should be safe to start passing them in. For now, I am only adding LTO, but more should be added in the future. There are two bugs here. One is that LTO flags aren't passed to rustdoc. The other is that the "doctest" unit was using the wrong profile (it was using dev/release when it should be using test/bench). There are two distinct scenarios here. One where just `release` has `lto` set. And one where both `release` and `bench` have `lto` set. This is relevant because LTO mostly cares about what the final artifact wants, and in the case where `bench` does not have `lto` set, then LTO will not be used for tests. This will hopefully be a little cleaner in the future when rust-lang#6988 is stabilized, which causes the test/bench profiles to *inherit* from the dev/bench profiles, which means you won't need to manually synchronize the test/bench profiles with dev/release. Fixes rust-lang#8654
This regression occurs in the beta:
Problem
cargo test --doc --releasefails with linker error "fatal error LNK1107: invalid or corrupt file: cannot read at 0xD2A" on Windows using MSVC 2019 whenlto = trueis in the release build profile, in the beta and nightly channels.cargo test --doc(non-release builds) succeeds.cargo test --doc --releasesucceeds in the current stable release,cargo 1.45.1 (f242df6ed 2020-07-22).Cargo.toml:
src/lib.rs:
The failures do not occur when the current stable cargo is used.
Possible Solution(s)
I suspect that PR #8192 or one of the follow-ups such as PR #8349 caused this regression.
Notes
This also occurs in Nightly. It has been occurring in nightly for several weeks, and in the last few weeks it has occurred in Beta. Thus, the regression most likely happened before the last promotion of Nightly to Beta.
I used Process Monitor to capture the command lines for Cargo 1.45.1:
and the current beta:
The command lines seem to be the same.
The text was updated successfully, but these errors were encountered: