Fix unsupported `std::sys::thread` after move
Fixes building std for any platform with an unsupported thread abstraction. This includes {aarch64,armv7,x86_64}-unknown-trusty and riscv32im-risc0-zkvm-elf, which explicitly include the unsupported module, and platforms with no PAL.
Bug fix for rust-lang/rust#145177 (std: move thread into sys).
Also fix the `std` build for xtensa, which I incidentally found while looking for an unsupported platform.
r? ``@joboet``
Fixes building std for any platform with an unsupported thread
abstraction. This includes {aarch64,armv7,x86_64}-unknown-trusty and
riscv32im-risc0-zkvm-elf, which explicitly include the unsupported
module, and platforms with no PAL.
Bug fix for PR 145177 (std: move thread into sys).
Migrate the standard library from using the external `cfg_if` crate to
using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from
`library/std/Cargo.toml`, because while the standard library itself no
longer uses `cfg_if`, it also incorporates the `backtrace` crate, which
does.
Migration assisted by the following vim command (after selecting the
full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This
prompts for confirmation on the `} else {` since that can also appear
inside one of the arms. This also requires manual intervention to handle
any multi-line conditions.
The `security_attributes` function is marked as safe despite taking a raw pointer which will later be used. Fortunately this function is only used internally and only in one place that has been basically the same for a decade now.
However, we only ever set one bool so it's easy enough to replace with something that's actually safe.
Add a setsid method to the CommandExt trait so that callers can create
a process in a new session and process group whilst still using the
POSIX spawn fast path.
Co-Authored-By: Harvey Hunt <harveyhunt@fb.com>
`CStringArray` contained both `CString`s and their pointers. Unfortunately, since `CString` uses `Box`, moving the `CString`s into the `Vec` can (under stacked borrows) invalidate the pointer to the string, meaning the resulting `Vec<*const c_char>` was, from an opsem perspective, unusable. This PR removes removes the `Vec<CString>` from `CStringArray`, instead recreating the `CString`/`CStr` from the pointers when necessary. Also,`CStringArray` is now used for the process args as well, the old implementation was suffering from the same kind of bug.
This adds a `chroot` method to the `CommandExt` extension trait for the
`Command` builder, to set a directory to chroot into. This will chroot
the child process into that directory right before calling chdir for the
`Command`'s working directory.
To avoid allowing a process to have a working directory outside of the
chroot, if the `Command` does not yet have a working directory set,
`chroot` will set its working directory to "/".
collect all Fuchsia bindings into the `fuchsia` module
The Fuchsia bindings are currently spread out across multiple modules in `sys/pal/unix` leading to unnecessary duplication. This PR moves all of these definitions into `sys::pal::unix::fuchsia` and additionally:
* deduplicates the definitions
* makes the error names consistent
* marks `zx_thread_self` and `zx_clock_get_monotonic` as safe extern functions
* removes unused items (there's no need to maintain these bindings if we're not going to use them)
* removes the documentation for the definitions (contributors should always consult the platform documentation, duplicating that here is just an extra maintenance burden)
`@rustbot` ping fuchsia
The Fuchsia bindings are currently spread out across multiple modules in `sys/pal/unix` leading to unnecessary duplication. This PR moves all of these definitions into `sys::pal::unix::fuchsia` and additionally:
* deduplicates the definitions
* makes the error names consistent
* marks some extern functions as safe
* removes unused items (there's no need to maintain these bindings if we're not going to use them)
* removes the documentation for the definitions (contributors should always consult the platform documentation, duplicating that here is just an extra maintenance burden)
Move the public `CommandEnvs` into the `process` module (and make it a wrapper type for an internal iterator type) and everything else into `sys::process` as per #117276.
Move `sys::pal::os::Env` into `sys::env`
Although `Env` (as `Vars`), `Args`, path functions, and OS constants are publicly exposed via `std::env`, their implementations are each self-contained. Keep them separate in `std::sys` and make a new module, `sys::env`, for `Env`.
Also fix `unsafe_op_in_unsafe_fn` for Unix and update the `!DynSend` and `!DynSync` impls which had grown out of sync with the platforms (see #48005 for discussion on that).
r? joboet
Tracked in #117276.
Although `Env` (as `Vars`), `Args`, path functions, and OS constants are
publicly exposed via `std::env`, their implementations are each
self-contained. Keep them separate in `std::sys` and make a new module,
`sys::env`, for `Env`.
std: sys: process: uefi: Use NULL stdin by default
According to the docs in `Command::output`:
> By default, stdout and stderr are captured (and used to provide the
resulting output). Stdin is not inherited from the parent and any attempt by the child process to read from the stdin stream will result in the stream immediately closing.
This was being violated by UEFI which was inheriting stdin by default.
While the docs don't explicitly state that the default should be NULL, the behaviour seems like reading from NULL.
UEFI however, has a bit of a problem. The `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` only provides support for reading 1 key press. This means that you either get an error, or it is assumed that the keypress was read successfully. So there is no way to have a successful read of length 0. Currently, I am returning UNSUPPORTED error when trying to read from NULL stdin. On linux however, you will get a read of length 0 for Null stdin.
One possible way to get around this is to translate one of the UEFI errors to a read 0 (Maybe unsupported?). It is also possible to have a non-standard error code, but well, not sure if we go that route.
Alternatively, if meaning of Stdio::Null is platform dependent, it should be fine to keep the current behaviour of returning an error.
cc ```@nicholasbishop``` ```@dvdhrm```
Stdio::MakePipe is not supported.
For Stdio::Null, return UNSUPPORTED. This is treated as read(0).
Additionally, have infinte loop on the notify function to prevent
wait_for_key from returning.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
According to the docs in `Command::output`:
> By default, stdout and stderr are captured (and used to provide the
resulting output). Stdin is not inherited from the parent and any attempt
by the child process to read from the stdin stream will result in the
stream immediately closing.
This was being violated by UEFI which was inheriting stdin by default.
While the docs don't explicitly state that the default should be NULL,
the behaviour seems like reading from NULL.
UEFI however, has a bit of a problem. The `EFI_SIMPLE_TEXT_INPUT_PROTOCOL`
only provides support for reading 1 key press. This means that you
either get an error, or it is assumed that the keypress was read
successfully. So there is no way to have a successful read of length 0.
Currently, I am returning UNSUPPORTED error when trying to read from
NULL stdin. On linux however, you will get a read of length 0 for Null
stdin.
One possible way to get around this is to translate one of the UEFI
errors to a read 0 (Maybe unsupported?). It is also possible to have a
non-standard error code, but well, not sure if we go that route.
Alternatively, if meaning of Stdio::Null is platform dependent, it
should be fine to keep the current behaviour of returning an error.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Try not to use verbatim paths in `Command::current_dir`
If possible, we should try not to use verbatim paths in `Command::current_dir`. It might work but it might also break code in the subprocess that assume the current directory isn't verbatim (including Windows APIs). cc ``@ehuss``
Side note: we now have a lot of ad-hoc fixes like this spread about the place. It'd be good to make a proper `WindowsPath` type that handles all this in one place. But that's a bigger job for another PR.
If possible, we should try not to use verbatim paths in Command::current_dir. It might work but it might also break code (including some Windows APIs) that assume the current directory isn't verbatim.
Change the syntax to include parameter names and a trailing semicolon.
Motivation:
- Mirror the `syscall!` macro.
- Allow rustfmt to format it (when wrapped in parentheses).
- For better documentation (having the parameter names available in
the source code is a bit nicer).
- Allow future improvements to this macro where we can sometimes use the
symbol directly when it's statically known to be available.
As per #117276, this moves the implementations of `Process` and friends out of the `pal` module and into the `sys` module, removing quite a lot of error-prone `#[path]` imports in the process (hah, get it ;-)). I've also made the `zircon` module a dedicated submodule of `pal::unix`, hopefully we can move some other definitions there as well (they are currently quite a lot of duplications in `sys`). Also, the `ensure_no_nuls` function on Windows now lives in `sys::pal::windows` – it's not specific to processes and shared by the argument implementation.
