Description
Update 2021-12-27: More minimized MCVE at repo here (also linked from comment below.)
I tried this code (note that the crate name needs to match its usage in the doc test to reproduce the bug properly):
# Cargo.toml
[package]
name = "a64_doctestfail"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
tokio = { version = "0.2", features = ["full"] }
[profile.release]
lto = true
// lib.rs
pub fn bad() {
let _ = tokio::runtime::Builder::new();
}
/// ```
/// use a64_doctestfail;
/// ```
pub struct X;
And then ran cargo --release --doc
.
I expected to see this happen:
(Working behavior from 1.56.1, witnessed via nightly-2021-10-13)
% cargo +nightly-2021-10-13 test --release --doc
Compiling a64_doctestfail v0.1.0 (/Users/pnkfelix/Dev/Rust/a64_doctestfail)
Finished release [optimized] target(s) in 0.09s
Doc-tests a64_doctestfail
running 1 test
test src/lib.rs - X (line 7) ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.19s
Instead, this happened:
(Broken behavior from 1.57.0, witnessed via nightly-2021-10-14)
% cargo +nightly-2021-10-14 test --release --doc
Finished release [optimized] target(s) in 0.01s
Doc-tests a64_doctestfail
running 1 test
test src/lib.rs - X (line 7) ... FAILED
failures:
---- src/lib.rs - X (line 7) stdout ----
Couldn't compile the test.
failures:
src/lib.rs - X (line 7)
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.68s
error: test failed, to rerun pass '--doc'
Meta
rustc +nightly-2021-10-14 --version --verbose
:
rustc 1.57.0-nightly (dfc5add 2021-10-13)
binary: rustc
commit-hash: dfc5add
commit-date: 2021-10-13
host: aarch64-apple-darwin
release: 1.57.0-nightly
LLVM version: 13.0.0
`rustc +stable --version --verbose`:
rustc 1.57.0 (f1edd04 2021-11-29)
binary: rustc
commit-hash: f1edd04
commit-date: 2021-11-29
host: aarch64-apple-darwin
release: 1.57.0
LLVM version: 13.0.0
Activity
pnkfelix commentedon Dec 8, 2021
(by the way, the reason that I didn't include
cargo-bisect-rustc
output above is that the tool was not working for me today for this target; some kind of failure in its attempts to download the pre-built binaries per-commit. I haven't looked in more detail into it; for all I know, maybe we don't keep per-commit builds for aarch64...)pnkfelix commentedon Dec 8, 2021
Here are the relevant commits over the period where this bug was injected:
% git log --author=bors d7c97a02d..dfc5add91 --format=oneline
:pnkfelix commentedon Dec 8, 2021
(it would be good to further minimize this. if possible I'd like to rewrite it as a normal test rather than a rustdoc one, if possible.)
jyn514 commentedon Dec 8, 2021
@pnkfelix can you run
cargo test --release --doc -- --nocapture
and post the output? I think rustdoc is hiding the actual compile error.jyn514 commentedon Dec 8, 2021
It seems strange this only happens with doctests - does it also happen if you add a second crate that depends on
a64_doctestfail
(without a doctest)?hkratz commentedon Dec 8, 2021
Bisecting worked fine for me. The regression pinpointed to the cargo update #89802
bisected with cargo-bisect-rustc v0.6.1
searched toolchains d7c97a0 through dfc5add
Regression in a16f686
searched nightlies: from nightly-2021-10-13 to nightly-2021-12-08
regressed nightly: nightly-2021-10-14
searched commit range: d7c97a0...dfc5add
regressed commit: a16f686
Host triple: aarch64-apple-darwin
Reproduce with:
cargo bisect-rustc 2021-10-13 -- test --release --doc -- --nocapture
pnkfelix commentedon Dec 8, 2021
Adding
--nocapture
alone does not seem to help here. I think you are right thatrustdoc
is hiding the actual compiler error; but I also think that we need to go deeper to dig out the root cause. (I do wish that--nocapture
did resolve it, or some better still, some set of--verbose
flags...)pnkfelix commentedon Dec 8, 2021
I figured out how to use
rustdoc --test-builder
to feed in a wrapper script aroundrustc
that also emits the arguments that were passed intorustc
. That should hopefully be enough for me to narrow this down to a bug that doesn't rely onrustdoc
for us to replicate it.23 remaining items
lto = "thin"
causes SIGSEGVs when ran under rustdoc rayon-rs/rayon#911cuviper commentedon Jan 11, 2022
I was just debugging rayon-rs/rayon#911 that also bisected to the cargo update in #89802, which led me to this issue. This is another case of rustdoc + LTO failure, but instead of a compiler crash I've got bad codegen that crashes at runtime. I'm hoping it's the same root cause in LLVM that we're both looking for, so maybe that different angle will help.
lto = "thin"
causesdoctest
to generate invalid code on rust-1.57 #92869pnkfelix commentedon Jan 19, 2022
(I'm going to count the MCVE from my repo as good enough to remove the E-needs-mcve from this ticket.)
@rustbot label: -E-needs-mcve
pnkfelix commentedon Jan 21, 2022
Sweet, @nikic massively reduced the test case further (from LLVM's perspective) and has a candidate patch up; see progress over on llvm/llvm-project#53315
pnkfelix commentedon Jan 24, 2022
On the LLVM side, this was fixed by llvm/llvm-project@0d1308a
i'm going to see about cherry-picking that into the rustc local fork of LLVM.
pnkfelix commentedon Jan 28, 2022
(I'm not sure there's much value in encoding this specific reproducer as a regression test for rustc, since its so tightly coupled to LLVM-IR details... so I didn't include a regression test in the PR #93426. But I'm open to counter-arguments...)
Auto merge of rust-lang#93426 - pnkfelix:issue-91671-backport-llvm-fi…
Rollup merge of rust-lang#93331 - pnkfelix:refactor-write-output-file…