Skip to content

Can we get rid of the lib.miri.rs hack now? #137479

Open
@RalfJung

Description

@RalfJung

We added some quite elaborate hacks in bootstrap and Miri to support ./x miri running standard library tests in Miri. This comment explains why:

            // This hack helps bootstrap run standard library tests in Miri. The issue is as
            // follows: when running `cargo miri test` on libcore, cargo builds a local copy of core
            // and makes it a dependency of the integration test crate. This copy duplicates all the
            // lang items, so the build fails. (Regular testing avoids this because the sysroot is a
            // literal copy of what `cargo build` produces, but since Miri builds its own sysroot
            // this does not work for us.) So we need to make it so that the locally built libcore
            // contains all the items from `core`, but does not re-define them -- we want to replace
            // the entire crate but a re-export of the sysroot crate. We do this by swapping out the
            // source file: if `MIRI_REPLACE_LIBRS_IF_NOT_TEST` is set and we are building a
            // `lib.rs` file, and a `lib.miri.rs` file exists in the same folder, we build that
            // instead. But crucially we only do that for the library, not the test builds.

Turns out this is problematic not just for Miri but for everyone who wants to run the test suite, so @bjorn3 is moving things around to avoid the underlying issue (#135937, #136642). Once that is done, we can probably get rid of the hacks in Miri.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-miriArea: The miri toolC-cleanupCategory: PRs that clean code up or issues documenting cleanup.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