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>
