PR https://github.com/rust-lang/rust/pull/66512 added the ability to set argv[0] on
Command. As a side effect, it changed the Debug output to print both the program and
argv[0], which in practice results in stuttery output ("echo echo foo").
This PR reverts the behaviour to the the old one, so that the command is only printed
once - unless arg0 has been set. In that case it emits "[command] arg0 arg1 ...".
This commit applies rustfmt with rust-lang/rust's default settings to
files in src/libstd/sys *that are not involved in any currently open PR*
to minimize merge conflicts. THe list of files involved in open PRs was
determined by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in outstanding_files, the
relevant commands were:
$ find src/libstd/sys -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd/sys outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of the files.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
This allows argv[0] to be overridden on the executable's command-line. This also makes the program
executed independent of argv[0].
Does Fuchsia have the same semantics?
Addresses: #66510
Fuchsia exit codes don't follow the convention of libc::WEXITSTATUS et
al, and they are 64 bits instead of 32 bits. This gives Fuchsia its own
representation of ExitStatus.
Additionally, the zircon syscall structs were out of date, causing us to
see bogus return codes.
libstd fuchsia fixes
This fixes two bugs in libstd on Fuchsia:
- `zx_time_t` was changed to an `i64`, but this never made it into libstd
- When spawning processes where any of the stdio were null, libstd attempts to open `/dev/null`, which doesn't exist on Fuchsia
r? @cramertj
This commit rejiggers the generics used in the implementation of
`Command::env` with the purpose of reducing the amount of codegen that
needs to happen in consumer crates, instead preferring to generate code
into libstd.
This was found when profiling the compile times of the `cc` crate where
the binary rlib produced had a lot of `BTreeMap` code compiled into it
but the crate doesn't actually use `BTreeMap`. It turns out that
`Command::env` is generic enough to codegen the entire implementation in
calling crates, but in this case there's no performance concern so it's
fine to compile the code into the standard library.
This change is done by removing the generic on the `CommandEnv` map
which is intended to handle case-insensitive variables on Windows.
Instead now a generic isn't used but rather a `use` statement defined
per-platform is used.
With this commit a debug build of `Command::new("foo").env("a", "b")`
drops from 21k lines of LLVM IR to 10k.
In sys/unix/process, we work around the sigemptyset linking issues
on android in two different ways. This change consolidates these
workarounds, and avoids duplicating bindings from `libc`.
For `libc` types that will be initialized in FFI calls, we can just use
`MaybeUninit` and then pass around raw pointers.
For `sun_path_offset()`, which really wants `offset_of`, all callers
have a real `sockaddr_un` available, so we can use that reference.
This is a non-POSIX extension implemented in Solaris and in glibc 2.29.
With this we can still use `posix_spawn()` when `Command::current_dir()`
has been set, otherwise we fallback to `fork(); chdir(); exec()`.
This commit, after reverting #55359, applies a different fix for #46775
while also fixing #55775. The basic idea was to go back to pre-#55359
libstd, and then fix#46775 in a way that doesn't expose #55775.
The issue described in #46775 boils down to two problems:
* First, the global environment is reset during `exec` but, but if the
`exec` call fails then the global environment was a dangling pointer
into free'd memory as the block of memory was deallocated when
`Command` is dropped. This is fixed in this commit by installing a
`Drop` stack object which ensures that the `environ` pointer is
preserved on a failing `exec`.
* Second, the global environment was accessed in an unsynchronized
fashion during `exec`. This was fixed by ensuring that the
Rust-specific environment lock is acquired for these system-level
operations.
Thanks to Alex Gaynor for pioneering the solution here!
Closes#55775
Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
Instead, pass the environment to execvpe, so the kernel can apply it directly to the new process. This avoids a use-after-free in the case where exec'ing the new process fails for any reason, as well as a race condition if there are other threads alive during the exec.
These were showing up in tests and in binaries but are trivially optimize-able
away, so add `#[inline]` attributes so LLVM has an opportunity to optimize them
out.
The expected behavior is that the environment's PATH should be used
to find the process. posix_spawn() could be used if we iterated
PATH to search for the binary to execute. For now just skip
posix_spawn() if PATH is modified.
