You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Running ./x test mir-opt rebuilds std every time #131437
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.
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.
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.
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.
Reacted by Chris Denton, 许杰友 Jieyou Xu (Joe) and Urgau
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.
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.
Activity
Zalathar commentedon Oct 9, 2024
cc @jieyouxu
Zalathar commentedon Oct 9, 2024
I will note that
--keep-stage-std=1does seem to avoid the rebuild when re-running the tests.ChrisDenton commentedon Oct 9, 2024
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.
jieyouxu commentedon Oct 9, 2024
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.
onur-ozkan commentedon Oct 9, 2024
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.
jieyouxu commentedon Oct 9, 2024
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.jieyouxu commentedon Oct 9, 2024
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 differingRUSTFLAGS. The double std build was the dead giveaway that fortunately makes it very easy to tell what the rebuild was caused by.Rollup merge of rust-lang#131442 - jieyouxu:mir-opt-rebuild, r=onur-o…
Rollup merge of rust-lang#131442 - jieyouxu:mir-opt-rebuild, r=onur-o…
Rollup merge of rust-lang#131442 - jieyouxu:mir-opt-rebuild, r=onur-o…
Rollup merge of rust-lang#131442 - jieyouxu:mir-opt-rebuild, r=onur-o…
Rollup merge of rust-lang#131442 - jieyouxu:mir-opt-rebuild, r=onur-o…
Unrolled build for rust-lang#131442
./x.py test mir-optdirties build cache for standard library #128493 as a duplicate of this issue