-
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
ExitStatus Debug instance is misleading #74832
Comments
Looking into this in a bit more detail, my interpretation in the OP is wrong, but the C/POSIX standards are confusing for these things. Apparently exit status of a UNIX process an as output of waitpid in the parent, takes entirely different values to the exit status given as an input to #include <stdio.h>
void main() {
exit(11);
} then run the rust code again, it will output:
In other words,
I am not sure what to do about this bug report. The Debug instance is misleading, but it is not a direct fault of rust, but of the various systems it's running on top of. For sure I will file another PR to patch up rustbuild's rustc wrapper to use Display instead of Debug. |
…g#74832 for justification
rustbuild: use Display for exit status instead of Debug, see rust-lang#74832 for justification
These structs have misleading names. An ExitStatus[Error] is actually a Unix wait status; an ExitCode is actually an exit status. The Display impls are fixed, but the Debug impls are still misleading, as reported in rust-lang#74832. Fix this by pretending that these internal structs are called `unix_exit_status` and `unix_wait_status` as applicable. (We can't actually rename the structs because of the way that the cross-platform machinery works: the names are cross-platform.) Signed-off-by: Ian Jackson <[email protected]>
Manual Debug for Unix ExitCode ExitStatus ExitStatusError These structs have misleading names. An ExitStatus[Error] is actually a Unix wait status; an ExitCode is actually an exit status. These misleading names appear in the `Debug` output. The `Display` impls on Unix have been improved, but the `Debug` impls are still misleading, as reported in rust-lang#74832. Fix this by pretending that these internal structs are called `unix_exit_status` and `unix_wait_status` as applicable. (We can't actually rename the structs because of the way that the cross-platform machinery works: the names are cross-platform.) After this change, this program ``` #![feature(exit_status_error)] fn main(){ let x = std::process::Command::new("false").status().unwrap(); dbg!(x.exit_ok()); eprintln!("x={:?}",x); } ``` produces this output ``` [src/main.rs:4] x.exit_ok() = Err( ExitStatusError( unix_wait_status( 256, ), ), ) x=ExitStatus(unix_wait_status(256)) ``` Closes rust-lang#74832
On UNIX,
c_int
is an alias fori32
ori16
depending on the platform.ExitStatus
is a wrapper aroundc_int
. However its Debug instance only exposes the last few bits:test.c
running:
test.rs
running:
The Debug output makes it look like a regular exit, not a signal exit. This is relevant because this is what rustbuild's rustc wrapper does in
src/bootstrap/bin/rustc.rs
, making rustc builds harder to debug.As you can see I tried to recreate the weirdness with
XX
which as far as I can tell, follows the structure of howExitStatus
is defined. However I didn't recreate the platform-dependent logic in libstd/sys/mod.rs which also includesmissing_debug_implementations
which might be interfering with the derivation logic.The text was updated successfully, but these errors were encountered: