Skip to content

Miri tests fail since dependencies don't get properly rebuilt #143680

@RalfJung

Description

@RalfJung

Miri tests have a non-trivial set up for our ui tests to be able to have dependencies. The resulting build gets cached in a miri_ui subfolder of CARGO_TARGET_TMPDIR. However, it does not seem to get properly cleared when rustc itself changes: running Miri tests then often ends in ICEs such as

FAILED TEST: tests/pass-dep/libc/libc-pipe.rs
command: env -u RUSTFLAGS "/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage1/bin/cargo-miri" "miri" "run" "--target-dir" "/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/tmp/miri_ui/0" "--manifest-path" "test_dependencies/Cargo.toml" "--target=x86_64-unknown-linux-gnu" "--message-format=json"

full stderr:
   Compiling libc v0.2.171
   Compiling proc-macro2 v1.0.94
   Compiling getrandom v0.3.2
   Compiling rustix v1.0.5
   Compiling getrandom v0.1.16

thread 'rustc' panicked at compiler/rustc_serialize/src/opaque.rs:299:9:
MemDecoder exhausted
[...]
query stack during panic:
#0 [resolver_for_lowering_raw] getting the resolver for lowering
end of query stack
error: could not compile `proc-macro2` (lib)

Caused by:
  process didn't exit successfully: `/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage1/bin/cargo-miri /home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage1/bin/miri --crate-name proc_macro2 --edition=2021 /home/r/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/proc-macro2-1.0.94/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="proc-macro"' --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values("default", "nightly", "proc-macro", "span-locations"))' -C metadata=f1c273aa68d715b2 -C extra-filename=-68441a33a4df5d02 --out-dir /home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/tmp/miri_ui/0/miri/debug/deps -L dependency=/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/tmp/miri_ui/0/miri/debug/deps --extern unicode_ident=/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/tmp/miri_ui/0/miri/debug/deps/libunicode_ident-60c28ba4d5cae96d.rmeta --cap-lints allow --cfg wrap_proc_macro --check-cfg 'cfg(fuzzing)' --check-cfg 'cfg(no_is_available)' --check-cfg 'cfg(no_literal_byte_character)' --check-cfg 'cfg(no_literal_c_string)' --check-cfg 'cfg(no_source_text)' --check-cfg 'cfg(proc_macro_span)' --check-cfg 'cfg(procmacro2_backtrace)' --check-cfg 'cfg(procmacro2_nightly_testing)' --check-cfg 'cfg(procmacro2_semver_exempt)' --check-cfg 'cfg(randomize_layout)' --check-cfg 'cfg(span_locations)' --check-cfg 'cfg(super_unstable)' --check-cfg 'cfg(wrap_proc_macro)'` (exit status: 101)
warning: build failed, waiting for other jobs to finish...

We had this problem before and I fixed it by adding this:

// Miri has its own "target dir" for ui test dependencies. Make sure it gets cleared when
// the sysroot gets rebuilt, to avoid "found possibly newer version of crate `std`" errors.
if !builder.config.dry_run() {
let ui_test_dep_dir =
builder.stage_out(miri.build_compiler, Mode::ToolStd).join("miri_ui");
// The mtime of `miri_sysroot` changes when the sysroot gets rebuilt (also see
// <https://github.com/RalfJung/rustc-build-sysroot/commit/10ebcf60b80fe2c3dc765af0ff19fdc0da4b7466>).
// We can hence use that directly as a signal to clear the ui test dir.
build_stamp::clear_if_dirty(builder, &ui_test_dep_dir, &miri_sysroot);
}

But apparently something changed somewhere and now this does not work any more.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions