uefi: process: Add support for command environment variables
Set environment variables before launching the process and restore the prior variables after the program exists.
This is the same implementation as the one used by UEFI Shell Execute [0].
[0]: 2d2642f483/ShellPkg/Application/Shell/ShellProtocol.c (L1700)
Implement unstable `new_range` feature
Switches `a..b`, `a..`, and `a..=b` to resolve to the new range types.
For rust-lang/rfcs#3550
Tracking issue #123741
also adds the re-export that was missed in the original implementation of `new_range_api`
Move some std tests to integration tests
Unit tests directly inside of standard library crates require a very fragile way of building that is hard to reproduce outside of bootstrap.
Follow up to https://github.com/rust-lang/rust/pull/133859
docs: Documented Send and Sync requirements for Mutex + MutexGuard
This an attempt to continue where #123225 left off.
I did some light clean up from the work done in that PR.
I also documented the `!Send` + `Sync` implementations for `MutexGuard` to the best of my knowledge.
Let me know if I got anything wrong 😄fixes#122856
cc: ``@IoaNNUwU``
r? ``@joboet``
Improve documentation for file locking
Add notes to each method stating that locks get dropped on close.
Clarify the return values of the try methods: they're only defined if
the lock is held via a *different* file handle/descriptor. That goes
along with the documentation that calling them while holding a lock via
the *same* file handle/descriptor may deadlock.
Document the behavior of unlock if no lock is held.
r? `@m-ou-se`
(Documentation changes requested in https://github.com/rust-lang/rust/issues/130994 .)
uefi: Implement path
This PR is split off from https://github.com/rust-lang/rust/pull/135368 to reduce noise.
UEFI paths can be of 4 types:
1. Absolute Shell Path: Uses shell mappings
2. Absolute Device Path: this is what we want
3. Relative root: path relative to the current root.
4. Relative
Absolute shell path can be identified with `:` and Absolute Device path can be identified with `/`. Relative root path will start with `\`.
The algorithm is mostly taken from edk2 UEFI shell implementation and is somewhat simple. Check for the path type in order.
For Absolute Shell path, use `EFI_SHELL->GetDevicePathFromMap` to get a BorrowedDevicePath for the volume.
For Relative paths, we use the current working directory to construct the new path.
BorrowedDevicePath abstraction is needed to interact with `EFI_SHELL->GetDevicePathFromMap` which returns a Device Path Protocol with the lifetime of UEFI shell.
Absolute Shell paths cannot exist if UEFI shell is missing.
cc `@nicholasbishop`
Add notes to each method stating that locks get dropped on close.
Clarify the return values of the try methods: they're only defined if
the lock is held via a *different* file handle/descriptor. That goes
along with the documentation that calling them while holding a lock via
the *same* file handle/descriptor may deadlock.
Document the behavior of unlock if no lock is held.
Rollup of 8 pull requests
Successful merges:
- #133382 (Suggest considering casting fn item as fn pointer in more cases)
- #136092 (Test pipes also when not running on Windows and Linux simultaneously)
- #136190 (Remove duplicated code in RISC-V asm bad-reg test)
- #136192 (ci: remove unused windows runner)
- #136205 (Properly check that array length is valid type during built-in unsizing in index)
- #136211 (Update mdbook to 0.4.44)
- #136212 (Tweak `&mut self` suggestion span)
- #136214 (Make crate AST mutation accessible for driver callback)
r? `@ghost`
`@rustbot` modify labels: rollup
uefi: process: Fix args
- While working on process env support, I found that args were currently broken. Not sure how I missed it in the PR, but well here is the fix.
- Additionally, no point in adding space at the end of args.
- While working on process env support, I found that args were currently
broken. Not sure how I missed it in the PR, but well here is the fix.
- Additionally, no point in adding space at the end of args.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Move `std::io::pipe` code into its own file
Also update the docs for the new location, create a section "Platform-specific behavior", don't hide required imports for code examples.
Rollup of 7 pull requests
Successful merges:
- #133631 (Support QNX 7.1 with `io-sock`+libstd and QNX 8.0 (`no_std` only))
- #134358 (compiler: Set `target_abi = "ilp32e"` on all riscv32e targets)
- #135812 (Fix GDB `OsString` provider on Windows )
- #135842 (TRPL: more backward-compatible Edition changes)
- #135946 (Remove extra whitespace from rustdoc breadcrumbs for copypasting)
- #135953 (ci.py: check the return code in `run-local`)
- #136019 (Add an `unchecked_div` alias to the `Div<NonZero<_>>` impls)
r? `@ghost`
`@rustbot` modify labels: rollup
This removes two minor OnceLock tests which test private methods. The
rest of the tests should be more than enough to catch mistakes in those
private methods. Also makes ReentrantLock::try_lock public. And finally
it makes the mpmc tests actually run.
Support QNX 7.1 with `io-sock`+libstd and QNX 8.0 (`no_std` only)
Changes of this pull request:
1. Refactor code for qnx nto targets to share more code in file `nto_qnx.rs`
1. Add support for an additional network stack on nto qnx 7.1.
QNX 7.1 supports two network stacks:
1. `io-pkt`, which is default
2. `io-sock`, which is optional on 7.1 but default in QNX 8.0
As one can see in the [io-sock migration notes](https://www.qnx.com/developers/docs/7.1/index.html#com.qnx.doc.neutrino.io_sock/topic/migrate_app.html), this changes the libc API in a way similar to e.g. linux-gnu vs. linux-musl.
This change adds a new target which has a different value for `target_env`, so that e.g. libc can distinguish between both APIs.
2. Add initial support for QNX 8.0, thanks to AkhilTThomas. As it turned out, the problem with forking many processes still exists in QNX 8.0. Because if this, we are now using it for any QNX version (i.e. not check for `target_env` anymore).
Update emscripten std tests
This disables a bunch of emscripten tests that test things emscripten doesn't support and re-enables a whole bunch of tests which now work just fine on emscripten.
Tested with `EMCC_CFLAGS="-s MAXIMUM_MEMORY=2GB" ./x.py test library/ --target wasm32-unknown-emscripten`.
- Simplify some of the language
- Minor grammar fixes
- Don't imply that pipes *only* work across multiple processes; instead,
*suggest* that they're typically used across two or more separate
processes.
- Specify that portable applications cannot use multiple readers or
multiple writers for messages larger than a byte, due to potential
interleaving.
- Remove no-longer-referenced footnote URLs.
Fix set_name in thread mod for NuttX
Replace `pthread_set_name_np` with `pthread_setname_np` for NuttX in the `set_name` function, this change aligns the implementation with the correct API available on NuttX
This patch ensures thread naming works correctly on NuttX platforms.
See also:
0f9f8c91ad/src/unix/nuttx/mod.rs (L562)8f3a2a6f76/include/pthread.h (L511-L514)
Add `File already exists` error doc to `hard_link` function
## Description
If the link path already exists, the error `AlreadyExists` is returned. This commit adds this error to the docs.
I tested it with the current rust master version, this error was returned when there is already a link for the file is present.
This was the error returned:
```
[harshit:../Desktop/rust_compiler_testing/hard_link (master|…5)] cargo +stage1 run
Compiling hard_link v0.1.0 (/home/harshit/Desktop/rust_compiler_testing/hard_link)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.12s
Running `target/debug/hard_link`
Err(Os { code: 17, kind: AlreadyExists, message: "File exists" })
```
This is my first PR on rust, any suggestions on which issue I can take next are most welcome 😄Fixes#130117
Replace `pthread_set_name_np` with `pthread_setname_np` for NuttX in the `set_name` function,
this change aligns the implementation with the correct API available on NuttX
This patch ensures thread naming works correctly on NuttX platforms.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
