Skip to content

doc test "Couldn't compile the test" on aarch64 + LTO #91671

Closed
@pnkfelix

Description

@pnkfelix

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

added
C-bugCategory: This is a bug.
O-ArmTarget: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state
A-LTOArea: Link-time optimization (LTO)
on Dec 8, 2021
pnkfelix

pnkfelix commented on Dec 8, 2021

@pnkfelix
MemberAuthor

(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

pnkfelix commented on Dec 8, 2021

@pnkfelix
MemberAuthor

Here are the relevant commits over the period where this bug was injected:

% git log --author=bors d7c97a02d..dfc5add91 --format=oneline:

added
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
on Dec 8, 2021
added
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on Dec 8, 2021
pnkfelix

pnkfelix commented on Dec 8, 2021

@pnkfelix
MemberAuthor

(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.)

added
E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
on Dec 8, 2021
jyn514

jyn514 commented on Dec 8, 2021

@jyn514
Member

@pnkfelix can you run cargo test --release --doc -- --nocapture and post the output? I think rustdoc is hiding the actual compile error.

jyn514

jyn514 commented on Dec 8, 2021

@jyn514
Member

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

hkratz commented on Dec 8, 2021

@hkratz
Contributor

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

pnkfelix commented on Dec 8, 2021

@pnkfelix
MemberAuthor

@pnkfelix can you run cargo test --release --doc -- --nocapture and post the output? I think rustdoc is hiding the actual compile error.

Adding --nocapture alone does not seem to help here. I think you are right that rustdoc 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

pnkfelix commented on Dec 8, 2021

@pnkfelix
MemberAuthor

I figured out how to use rustdoc --test-builder to feed in a wrapper script around rustc that also emits the arguments that were passed into rustc. That should hopefully be enough for me to narrow this down to a bug that doesn't rely on rustdoc for us to replicate it.

23 remaining items

cuviper

cuviper commented on Jan 11, 2022

@cuviper
Member

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.

pnkfelix

pnkfelix commented on Jan 19, 2022

@pnkfelix
MemberAuthor

(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

removed
E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
on Jan 19, 2022
pnkfelix

pnkfelix commented on Jan 21, 2022

@pnkfelix
MemberAuthor

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

pnkfelix commented on Jan 24, 2022

@pnkfelix
MemberAuthor

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

pnkfelix commented on Jan 28, 2022

@pnkfelix
MemberAuthor

(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...)

added a commit that references this issue on Jan 28, 2022

Auto merge of rust-lang#93426 - pnkfelix:issue-91671-backport-llvm-fi…

e0a55f4
added a commit that references this issue on Jun 10, 2022

Rollup merge of rust-lang#93331 - pnkfelix:refactor-write-output-file…

0777113
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-LTOArea: Link-time optimization (LTO)C-bugCategory: This is a bug.I-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.O-ArmTarget: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 stateP-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    Participants

    @cuviper@pnkfelix@hkratz@jyn514@rustbot

    Issue actions

      doc test "Couldn't compile the test" on aarch64 + LTO · Issue #91671 · rust-lang/rust