-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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) |
Err(cmd.exec()) | ||
} | ||
|
||
#[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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably not call this exec_cmd anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
…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 env
on Debian.env
always returns exit code 0. This means that therustc
bootstrap wrapper always returns exit code 0 even when it fails. However, the crossbeam-utils build process (due to autocfg) relies onrustc
returning error exit codes when detecting CPU features, and ends up writingcargo:rustc-cfg=has_atomic_u128
even when it's not detected, because therustc
wrapper is always giving exit code 0.(This separately is causing our builds to try to compile rustc 40+ times, due to #74801.)