Skip to content

Running ./x test mir-opt rebuilds std every time #131437

Description

@Zalathar

Using profile = compiler, running ./x test mir-opt causes bootstrap to rebuild all of std before running the tests, even when the build cache ought to be warm from a previous ./x test mir-opt.

Needless to say, this is not very fun when actually trying to run one or more mir-opt tests.

Activity

  1. added
    A-contributor-roadblockArea: Makes things more difficult for new or seasoned contributors to Rust
    T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
    on Oct 9, 2024
  2. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Oct 9, 2024
  3. Zalathar commented on Oct 9, 2024

    @Zalathar
    MemberAuthor
  4. added
    C-bugCategory: This is a bug.
    and removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Oct 9, 2024
  5. self-assigned this
    on Oct 9, 2024
  6. Zalathar commented on Oct 9, 2024

    @Zalathar
    MemberAuthor

    I will note that --keep-stage-std=1 does seem to avoid the rebuild when re-running the tests.

  7. ChrisDenton commented on Oct 9, 2024

    @ChrisDenton
    Member

    Is there some way for CI to error on spurious rebuilds? I don't know what that would look like but this has happened in a few different places for different reasons so it'd be nice if there were some way to catch it early.

  8. jieyouxu commented on Oct 9, 2024

    @jieyouxu
    Member

    Usually the spurious rebuilds happen if you try to run the same command, twice. I don't think that's very tractable for CI, but am happy to be proven wrong. Maybe we can try to devise some kind of mechanism in bootstrap to make some invalidations impossible, but I don't know how such a mechanism would work in general.

  9. onur-ozkan commented on Oct 9, 2024

    @onur-ozkan
    Contributor

    One mechanism for that would be to keep the rustflags logic in a single sealed module, so they can't be set externally from the individual build steps, which means they can't invalidate the build cache. Next to that approach we can add test coverage to rustflags logic.

  10. jieyouxu commented on Oct 9, 2024

    @jieyouxu
    Member

    I opened a short-term immediate fix in #131442, but the long term solution to prevent resurrgence of RUSTFLAGS-induced invalidation is a proper prevention mechanism as described above.

  11. jieyouxu commented on Oct 9, 2024

    @jieyouxu
    Member

    Also this one actually builds same stage std twice for host if host == target (i.e. not cross-compile) because std was ensure'd twice with differing RUSTFLAGS. The double std build was the dead giveaway that fortunately makes it very easy to tell what the rebuild was caused by.

  12. added 3 commits that reference this issue on Oct 10, 2024
  13. added a commit that references this issue on Oct 10, 2024
  14. added a commit that references this issue on Oct 10, 2024
  15. added a commit that references this issue on Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-contributor-roadblockArea: Makes things more difficult for new or seasoned contributors to RustC-bugCategory: This is a bug.T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions