rustbuild: --no-fail-fast tries to compile rustc 40+ times (due to crossbeam-utils failure) before eventually failing #74801
Labels
C-bug
Category: This is a bug.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Comments
infinity0
changed the title
|
edited the bug title to clarify that it tries to compile the whole of rustc 40+ times, a massive waste of time |
jyn514
added
the
T-bootstrap
Manishearth
added a commit
to Manishearth/rust
that referenced
this issue
Jul 27, 2020
rustbuild: fix bad usage of UNIX exec() in rustc wrapper exec never returns, it replaces the current process. so anything after it is unreachable. that's not how exec_cmd() is used in the surrounding code We use `--on-fail env` on Debian. `env` always returns exit code 0. This means that the `rustc` bootstrap wrapper always returns exit code 0 even when it fails. However, the crossbeam-utils build process (due to autocfg) relies on `rustc` returning error exit codes when detecting CPU features, and ends up writing `cargo:rustc-cfg=has_atomic_u128` even when it's not detected, because the `rustc` wrapper is always giving exit code 0. (This separately is causing our builds to try to compile rustc 40+ times, due to rust-lang#74801.)
|
AFAICT, this is not trying to compile rustc 40+ times, it's just the tests for each rustc crate -- building those will always fail if a dependency like crossbeam-utils is failing to compile. I'm not sure what behavior is expected from no-fail-fast, though -- I don't think we have a good way of differentiating the different kinds of |
|
Triage: Is this still a problem? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See for example https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=amd64&ver=1.44.1%2Bdfsg1-1%7Eexp1&stamp=1594606550&raw=0 (warning, 30MB HTML), raw text 25MB where the error message "cannot find type
AtomicU128" crops up 46 times.Presumably this is because 46 things depend on crossbeam-utils. But then they should automatically fail when one of their dependencies has recorded a failure, instead of re-running the same command. (In other words --no-fail-fast should only move onto other targets whose dependencies haven't failed.)
It's hard to notice these failures, since the error messages quickly scroll out of view. I only noticed because I eventually realised the build really shouldn't be taking 3+ hours.
The text was updated successfully, but these errors were encountered: