Convert `Into<ExitStatus> for ExitStatusError` to `From<ExitStatusError> for ExitStatus` in `std::process`
Implementing suggestion from https://github.com/rust-lang/rust/issues/84908#issuecomment-912352902:
> I believe the impl on ExitStatusError should be
>
> ```rust
> impl From<ExitStatusError> for ExitStatus
> ```
>
> rather than
>
> ```rust
> impl Into<ExitStatus> for ExitStatusError
> ```
>
> (there is generally never anything implemented as `Into` first, because implementing `From` reflexively provides `Into`)
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.
fix a comment about assert_receiver_is_total_eq
"a type implements #[deriving]" doesn't make any sense, so I assume they meant "implement `Eq`"? Also the attribute is called `derive`.
error: unresolved link to `std::fmt::Error`
--> library/core/src/fmt/mod.rs:115:52
|
115 | /// This function will return an instance of [`std::fmt::Error`] on error.
|
|
= note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings`
Implement `From<{&,&mut} [T; N]>` for `Vec<T>` where `T: Clone`
Currently, if `T` implements `Clone`, we can create a `Vec<T>` from an `&[T]` or an `&mut [T]`, can we also support creating a `Vec<T>` from an `&[T; N]` or an `&mut [T; N]`? Also, do I need to add `#[inline]` to the implementation?
ACP: rust-lang/libs-team#220. [Accepted]
Closes#100880.
ConstParamTy: require Eq as supertrait
As discussed with `@BoxyUwu` [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/.60ConstParamTy.60.20and.20.60Eq.60).
We want to say that valtree equality on const generic params agrees with `==`, but that only makes sense if `==` actually exists, hence we should have an appropriate bound. Valtree equality is an equivalence relation, so such a type can always be `Eq` and not just `PartialEq`.
Properly print cstr literals in `proc_macro::Literal::to_string`
Previously we printed the contents of the string, rather than the actual string literal (e.g. `the c string` instead of `c"the c string"`).
Fixes#112820
cc #105723
Clarify example in `Pin::new_unchecked` docs
This example in the docs of `Pin::new_unchecked` puzzled me for a relatively long time. Now I understand that it comes down to the difference between dropping the `Pin` vs dropping the pinned value.
I have extended the explanation to highlight this difference. In my opinion it is clearer now, and I hope it helps others understand `Pin` better.
fix OS-specific I/O safety docs since the io_safety feature is stable
Looks like this text was forgotten to be updated when `io_safety` got stabilized: it still says "once the io_safety feature is stable".
Also adjust the wording a bit for how these docs relate to the general concept of I/O safety.
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>
Document panics on unsigned wrapping_div/rem calls (#116063)
Add missing `# Panics` sections to the `uint_impl!` macro, documenting that the `wrapping_rem/div` calls will panic if passed zero.
Add the `cfg_match!` macro
# Movitation
Adds a match-like version of the `cfg_if` crate without a RFC [for the same reasons that caused `matches!` to be included in the standard library](https://github.com/rust-lang/rust/pull/65479).
* General-purpose (not domain-specific)
* Simple (the implementation is short) and useful (things can become difficult with several `cfg`s)
* Very popular [on crates.io ](https://crates.io/crates/cfg-if) (currently 3th in all-time downloads)
* The two previous points combined make it number three in [left-pad index](https://twitter.com/bascule/status/1184523027888988160) score
```rust
match_cfg! {
cfg(unix) => {
fn foo() { /* unix specific functionality */ }
}
cfg(target_pointer_width = "32") => {
fn foo() { /* non-unix, 32-bit functionality */ }
}
_ => {
fn foo() { /* fallback implementation */ }
}
}
```
# Considerations
A match-like syntax feels more natural in the sense that each macro fragment resembles an arm but I personally don't mind switching to any other desired syntax.
The lack of `#[ ... ]` is intended to reduce typing, nevertheless, the same reasoning described above can also be applied to this aspect.
Since blocks are intended to only contain items, anything but `cfg` is not expected to be supported at the current or future time.
~~Credits goes to `@gnzlbg` because most of the code was shamelessly copied from https://github.com/gnzlbg/match_cfg.~~
Credits goes to `@alexcrichton` because most of the code was shamelessly copied from https://github.com/rust-lang/cfg-if.
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.`
without this, the only way to create a `LitKind::Byte` is by
doing `"b'a'".parse::<Literal>()`, this solves that by enabling
`Literal::byte_character(b'a')`
- 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.
Call panic_display directly in const_panic_fmt.
`panic_str` just directly calls `panic_display`. The only reason `panic_str` exists, is for a lint to detect an expansion of `panic_2015!(expr)` (which expands to `panic_str`).
It is `panic_display` that is hooked by const-eval, which is the reason we call it here.
Part of https://github.com/rust-lang/rust/issues/116005
r? ``@oli-obk``
Rename BoxMeUp to PanicPayload.
"BoxMeUp" is not very clear. Let's rename that to a description of what it actually represents: a panic payload.
This PR also renames the structs that implement this trait to have more descriptive names.
Part of https://github.com/rust-lang/rust/issues/116005
r? `@oli-obk`
