rustbuild: fix bad usage of UNIX exec() in rustc wrapper #74803
Conversation
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
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
| #[cfg(not(unix))] | ||
| fn exec_cmd(cmd: &mut Command) -> io::Result<i32> { | ||
| cmd.status().map(|status| status.code().unwrap()) | ||
| } |
There was a problem hiding this comment.
We should probably not call this exec_cmd anymore.
There was a problem hiding this comment.
Renamed in b99668b
|
@nagisa Bug has existed since your b3b2f1b (Dec 2016) - the very API of returning from a function that calls |
|
Wait, I think the motivation from b3b2f1b still stands for the proper rustc invocations, though, and only |
|
@nagisa I don't think the original motivation applies any more, and it's not used for that anyway - we intercept the status code and if there was a failure print the command line invocation. This would be impossible with exec. |
|
@bors r+ rollup |
|
📌 Commit b99668b has been approved by |
bors
added
S-waiting-on-bors
…arth Rollup of 4 pull requests Successful merges: - rust-lang#73858 (Make more primitive integer methods const) - rust-lang#74487 (Forbid generic parameters in anon consts inside of type defaults) - rust-lang#74803 (rustbuild: fix bad usage of UNIX exec() in rustc wrapper) - rust-lang#74822 (More ensure stack to avoid segfault with increased `recursion_limit`) Failed merges: r? @ghost
|
r? @nagisa |
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 envon Debian.envalways returns exit code 0. This means that therustcbootstrap wrapper always returns exit code 0 even when it fails. However, the crossbeam-utils build process (due to autocfg) relies onrustcreturning error exit codes when detecting CPU features, and ends up writingcargo:rustc-cfg=has_atomic_u128even when it's not detected, because therustcwrapper is always giving exit code 0.(This separately is causing our builds to try to compile rustc 40+ times, due to #74801.)