rust/library/std/src/sys/unix/process/process_unix, branch 1.56.0

Tolerate SIGTRAP for panic abort after panic::always_abort

2021-05-13T17:42:52+00:00

Some platforma (eg ARM64) apparently generate SIGTRAP for panic abort! See eg https://github.com/rust-lang/rust/pull/81858#issuecomment-840702765 This is probably a bug, but we don't want to entangle this MR with it. When it's fixed, this commit should be reverted. Signed-off-by: Ian Jackson

panic/fork test: Do not run on emscripten

2021-05-07T15:51:13+00:00

fork fails there. The failure message is confusing: so c.status() returns an Err, the closure panics, and the test thinks the panic was propagated from inside the child. Signed-off-by: Ian Jackson Co-authored-by: Mara Bos

panic ui test: Provide comprehensive test for panic after fork

2021-05-07T10:17:44+00:00

This tests that we can indeed safely panic after fork, both a raw libc::fork and in a Command pre_exec hook. Signed-off-by: Ian Jackson Co-authored-by: Mara Bos

panic tests: Command: Test that we do not unwind past fork

2021-05-07T10:17:44+00:00

This is safe (does not involve heap allocation) but we don't yet have a test to ensure that stays true. That will come in a moment. Signed-off-by: Ian Jackson Co-authored-by: Mara Bos

ExitStatus: print "exit status: {}" rather than "exit code: {}"

2021-03-25T10:27:53+00:00

Proper Unix terminology is "exit status" (vs "wait status"). "exit code" is imprecise on Unix and therefore unclear. (As far as I can tell, "exit code" is correct terminology on Windows.) This new wording is unfortunately inconsistent with the identifier names in the Rust stdlib. It is the identifier names that are wrong, as discussed at length in eg https://doc.rust-lang.org/nightly/std/process/struct.ExitStatus.html https://doc.rust-lang.org/nightly/std/os/unix/process/trait.ExitStatusExt.html Unfortunately for API stability reasons it would be a lot of work, and a lot of disruption, to change the names in the stdlib (eg to rename `std::process::ExitStatus` to `std::process::ChildStatus` or something), but we should fix the message output. Many (probably most) readers of these messages about exit statuses will be users and system administrators, not programmers, who won't even know that Rust has this wrong terminology. So I think the right thing is to fix the documentation (as I have already done) and, now, the terminology in the implementation. This is a user-visible change to the behaviour of all Rust programs which run Unix subprocesses. Hopefully no-one is matching against the exit status string, except perhaps in tests. Signed-off-by: Ian Jackson

Always compile the fragile wait status test cases, just run them conditionally

2021-03-09T10:53:03+00:00

Co-authored-by: David Tolnay

ExitStatus tests: Make less legible to satisfy "tidy"

2021-03-04T12:44:19+00:00

I strongly disagree with tidy in this case but AIUI there is no way to override it. Signed-off-by: Ian Jackson

ExitStatus unknown wait status test: Make it Linux only

2021-03-04T12:26:27+00:00

If different unices have different bit patterns for WIFSTOPPED and WIFCONTINUED then simply being glibc is probably not good enough for this rather ad-hoc test to work. Do it on Linux only. Signed-off-by: Ian Jackson

ExitStatus stop signal display test: Make it Linux only

2021-03-04T12:18:04+00:00

MacOS uses a different representation. Signed-off-by: Ian Jackson

process::unix: Test wait status formatting

2021-02-23T00:58:10+00:00

Signed-off-by: Ian Jackson