Implement sys::args for UEFI
- Uses `EFI_LOADED_IMAGE_PROTOCOL`, which is implemented for all loaded images.
Tested on qemu with OVMF
cc ``@nicholasbishop``
cc ``@dvdhrm``
Make `try_exists` return `Ok(true)` for Windows Unix Sockets
This is a follow up to #109106 but for[ `fs::try_exists`](https://doc.rust-lang.org/std/fs/fn.try_exists.html), which doesn't need to get the metadata of a file (which can fail even if a file exists).
`fs::try_exists` currently fails on Windows if encountering a Unix Domain Socket (UDS). This PR fixes it by checking for an error code that's returned when there's a failure to use a reparse point.
## Reparse points
A reparse point is a way to invoke a filesystem filter on a file instead of the file being opened normally. This is used to implement symbolic links (by redirecting to a different path) but also to implement other types of special files such as Unix domain sockets. If the reparse point is not a link type then opening it with `CreateFileW` may fail with `ERROR_CANT_ACCESS_FILE` because the filesystem filter does not implement that operation. This differs from resolving links which may fail with errors such as `ERROR_FILE_NOT_FOUND` or `ERROR_CANT_RESOLVE_FILENAME`.
So `ERROR_CANT_ACCESS_FILE` means that the file exists but that we can't open it normally. Still, the file does exist on the filesystem so `try_exists` should report that as `Ok(true)`.
r? libs
Fix exit status / wait status on non-Unix cfg(unix) platforms
Fixes#114593
Needs FCP due to behavioural changes (NB only on non-Unix `#[cfg(unix)]` platforms).
Also, I think this is likely to break in CI. I have not been yet able to compile the new bits of `process_unsupported.rs`, although I have compiled the new module. I'd like some help from people familiar with eg emscripten and fuchsia (which are going to be affected, I think).
`fs::try_exists` currently fails on Windows if encountering a Unix Domain Socket (UDS). Fix this by checking for an error code that's returned when there's a failure to use a reparse point.
A reparse point is a way to invoke a filesystem filter on a file instead of the file being opened normally. This is used to implement symbolic links (by redirecting to a different path) but also to implement other types of special files such as Unix domain sockets. If the reparse point is not a link type then opening it with `CreateFileW` may fail with `ERROR_CANT_ACCESS_FILE` because the filesystem filter does not implement that operation. This differs from resolving links which may fail with errors such as `ERROR_FILE_NOT_FOUND` or `ERROR_CANT_RESOLVE_FILENAME`.
So `ERROR_CANT_ACCESS_FILE` means that the file exists but that we can't open it normally. Still, the file does exist so `try_exists` should report that as `Ok(true)`.
Rollup of 4 pull requests
Successful merges:
- #116277 (dont call mir.post_mono_checks in codegen)
- #116400 (Detect missing `=>` after match guard during parsing)
- #116458 (Properly export function defined in test which uses global_asm!())
- #116500 (Add tvOS to target_os for register_dtor)
r? `@ghost`
`@rustbot` modify labels: rollup
`waitqueue` clarifications for SGX platform
The documentation of `waitqueue` functions on the `x86_64-fortanix-unknown-sgx` platform is incorrect at some places and on others missing. This PR improves upon this.
cc: `@jethrogb`
Works around #115199 by temporarily disabling CFI for core and std CFI
violations to allow the user rebuild and use both core and std with CFI
enabled using the Cargo build-std feature.
Add missing #[inline] on AsFd impl for sys::unix::fs::File
This operation should be extremely cheap, at most the `mov` of the underlying file descriptor, but due to this missing `#[inline]` it is currently a function call.
Stdio support for UEFI
- Uses Simple Text Output Protocol and Simple Text Input Protocol
- Reading is done one character at a time
- Writing is done with max 4096 characters
# Quirks
## Output Newline
- UEFI uses CRLF for newline. So when running the application in UEFI shell (qemu VGA), the output of `println` looks weird.
- However, since the UEFI shell supports piping output, I am unsure if doing any output post-processing is a good idea. UEFI shell `cat` command seems to work fine with just LF.
## Input Newline
- `Stdin.read_line()` method is broken in UEFI shell. Pressing enter seems to be read as CR, which means LF is never encountered.
- Works fine with input redirection from file.
CC `@dvdhrm`
- Uses Simple Text Output Protocol and Simple Text Input Protocol
- Reading is done one character at a time
- Writing is done with max 4096 characters
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
This operation should be extremely cheap, at most the mov of the underlying
file descriptor, but due to this missing #[inline] it is currently a function
call.
Update windows ffi bindings
Bump `windows-bindgen` to version 0.51.1. This brings with it some changes to the generated FFI bindings, but little that affects the code.
One change that does have more of an impact is `SOCKET` being `usize` instead of either `u64` or `u32` (as is used in std's public `SOCKET` type). However, it's now easy enough to abstract over that difference.
Finally I added a few new bindings that are likely to be used in pending PRs, mostly to make sure they're ok with the new metadata.
r? libs
Implement From<OwnedFd/Handle> for ChildStdin/out/err object
## Summary
Comments in `library/std/src/process.rs` ( ab08639e59 ) indicates that `ChildStdin`, `ChildStdout`, `ChildStderr` implements some traits that are not actually implemented: `FromRawFd`, `FromRawHandle`, and the `From<OwnedFd>/From<OwnedHandle>` from the io_safety feature.
In this PR I implement `FromRawHandle` and `FromRawFd` for those 3 objects.
## Usecase
I have a usecase where those implementations are basically needed. I want to customize
in the `Command::spawn` API how the pipes for the parent/child communications are created (mainly to strengthen the security attributes on them). I can properly setup the pipes,
and the "child" handles can be provided to `Child::spawn` easily using `Stdio::from_raw_handle`. However, there is no way to generate the `ChildStd*` objects from the raw handle of the created name pipe, which would be very useful to still expose the same API
than in other OS (basically a `spawn(...) -> (Child, ChildStdin, ChildStdout, ChildSterr)`, where on windows this is customized), and to for example use `tokio::ChildStdin::from_std` afterwards.
## Questions
* Are those impls OK to add? I have searched to see if those impls were missing on purpose, or if it was just never implemented because never needed. I haven't found any indication on why they couldn't be added, although the user clearly has to be very careful that the handle provided makes sense (i think, mainly that it is in overlapped mode for windows).
* If this change is ok, adding the impls for the io_safety feature would probably be best, or should it be done in another PR?
* I just copy-pasted the `#[stable(...)]` attributes, but the `since` value has to be updated, I'm not sure to which value.
Add Minimal Std implementation for UEFI
# Implemented modules:
1. alloc
2. os_str
3. env
4. math
# Related Links
Tracking Issue: https://github.com/rust-lang/rust/issues/100499
API Change Proposal: https://github.com/rust-lang/libs-team/issues/87
# Additional Information
This was originally part of https://github.com/rust-lang/rust/pull/100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from `@dvdhrm,` I have extracted a minimal std implementation to this PR.
The example in `src/doc/rustc/src/platform-support/unknown-uefi.md` has been tested for `x86_64-unknown-uefi` and `i686-unknown-uefi` in OVMF. It would be great if someone more familiar with AARCH64 can help with testing for that target.
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Raise minimum supported Apple OS versions
This implements the proposal to raise the minimum supported Apple OS versions as laid out in the now-completed MCP (https://github.com/rust-lang/compiler-team/issues/556).
As of this PR, rustc and the stdlib now support these versions as the baseline:
- macOS: 10.12 Sierra
- iOS: 10
- tvOS: 10
- watchOS: 5 (Unchanged)
In addition to everything this breaks indirectly, these changes also erase the `armv7-apple-ios` target (currently tier 3) because the oldest supported iOS device now uses ARMv7s. Not sure what the policy around tier3 target removal is but shimming it is not an option due to the linker refusing.
[Per comment](https://github.com/rust-lang/compiler-team/issues/556#issuecomment-1297175073), this requires a FCP to merge. cc `@wesleywiser.`
- Some comment fixes.
- Make some functions unsafe.
- Make helpers module private.
- Rebase on master
- Update r-efi to v4.2.0
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
- Make BootServices unavailable if ExitBootServices event is signaled.
- Use thread locals for SystemTable and ImageHandle
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Command: also print removed env vars
There is no real shell syntax for unsetting an env var so easily, so we have to make one up. But we already do that for showing the 'program' name so I hope that's okay here, too. No strong opinion on what that should look like, I went with `unset(VAR_NAME)` for now.
Add initial libstd support for Xous
This patchset adds some minimal support to the tier-3 target `riscv32imac-unknown-xous-elf`. The following features are supported:
* alloc
* thread creation and joining
* thread sleeping
* thread_local
* panic_abort
* mutex
* condvar
* stdout
Additionally, internal support for the various Xous primitives surrounding IPC have been added as part of the Xous FFI. These may be exposed as part of `std::os::xous::ffi` in the future, however for now they are not public.
This represents the minimum viable product. A future patchset will add support for networking and filesystem support.
Allow redirecting subprocess stdout to our stderr etc. (redux)
This is the code from #88561, tidied up, including review suggestions, and with the for-testing-only CI commit removed. FCP for the API completed in #88561.
I have made a new MR to facilitate review. The discussion there is very cluttered and the branch is full of changes (in many cases as a result of changes to other Rust stdlib APIs since then). Assuming this MR is approvedl we should close that one.
### Reviewer doing a de novo review
Just code review these four commits.. FCP discussion starts here: https://github.com/rust-lang/rust/pull/88561#issuecomment-1640527595
Portability tests: you can see that this branch works on Windows too by looking at the CI results in #88561, which has the same code changes as this branch but with an additional "DO NOT MERGE" commit to make the Windows tests run.
### Reviewer doing an incremental review from some version of #88561
Review the new commits since your last review. I haven't force pushed the branch there.
git diff the two branches (eg `git diff 176886197d6..0842b69c219`). You'll see that the only difference is in gitlab CI files. You can also see that *this* MR doesn't touch those files.
This implementation is wrong. Like the impl for From<File>, it is
forced to panic because process::Stdio in unsupported/process.rs
doesn't have a suitable variant.
The root cause of the problem is that process::Stdio in
unsupported/process.rs has any information in it at all.
I'm pretty sure that it should just be a unit struct. However,
making that build on all platforms is going to be a lot of work,
iterating through CI and/or wrestling Docker.
I don't think this extra panic is making things significantly worse.
For now I have added some TODOs.
Move RawOsError defination to sys
This was originally a part of https://github.com/rust-lang/rust/pull/105861, but I feel it should be its own PR since the raw os error is still unstable.
