Update subtree/library to 2025-08-13 #460
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
UEFI networking APIs do support vectored read/write. While the types for UDP4, UDP6, TCP4 and TCP6 are defined separately, they are essentially the same C struct. So we can map IoSlice and IoSliceMut to have the same binary representation. Since all UEFI networking types for read/write are DSTs, `IoSlice` and `IoSliceMut` will need to be copied to the end of the transmit/receive structures. So having the same binary representation just allows us to do a single memcpy instead of having to loop and set the DST. Signed-off-by: Ayush Singh <[email protected]>
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.
…ibutes explicitly
…ctors_lite, r=ChrisDenton Stabilize `duration_constructors_lite` feature This closes [tracking issue](rust-lang#140881) and stabilises `Duration::from_hours` and `Duration::from_mins` while not touching a `duration_constructors` feature from the related [tracking issue (2)](rust-lang#120301)
…-section, r=joshtriplett
`{BTree,Hash}Map`: add "`Entry` API" section heading
I wanted to link to an introduction of the `Entry` API to the help message of `clippy::map_entry` (see rust-lang/rust-clippy#11598 for motivation), but I found the documentation on the `Entry` enum itself a bit short. On the other hand, `{BTree,Hash}Map` both have sections in their docs introducing the whole API and giving usage examples, and so I would like to link to that instead. For that, I introduce the "`Entry` API" section heading to both of them.
Do let me know whether you think this is the right approach.
…crum Replace unsafe `security_attributes` function with safe `inherit_handle` alternative 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. In the future we might want to expose the ability for users to set security attributes. But that should be properly designed (and safe!).
…nieu Constify remaining traits/impls for `const_ops` Tracking issue: rust-lang#143802 This is split into two commits for ease of reviewability: 1. Updates the `forward_ref_*` macros to accept multiple attributes (in anticipation of needing `rust_const_unstable` attributes) and also *require* attributes in these macros. Since the default attribute only helps for the initial implementations, it means it's easy to get wrong for future implementations, as shown for the saturating implementations which were incorrect before. 2. Actually constify the traits/impls. A few random other notes on the implementation specifically: * I unindented the attributes that were passed to the `forward_ref_*` macro calls because in some places rustfmt wanted them to be unindented, and in others it was allowed because they were themselves inside of macro bodies. I chose the consistent indenting even though I (personally) think it looks worse. ---- As far as the actual changes go, this constifies the following additional traits: * `Neg` * `Not` * `BitAnd` * `BitOr` * `BitXor` * `Shl` * `Shr` * `AddAssign` * `SubAssign` * `MulAssign` * `DivAssign` * `RemAssign` * `BitAndAssign` * `BitOrAssign` * `BitXorAssign` * `ShlAssign` * `ShrAssign` In terms of constified implementations of these traits, it adds the reference-forwarded versions of all the arithmetic operators, which are defined by the macros in `library/core/src/internal_macros.rs`. I'm not going to fully enumerate these because we'd be here all day, but sufficed to say, it effectively allows adding an `&` to one or both sides of an operator for primitives. Additionally, I constified the implementations for `Wrapping`, `Saturating`, and `NonZero` as well, since all of them forward to already-const-stable methods. (potentially via intrinsics, to avoid extra overhead) There are three "non-primitive" types which implement these traits, listed below. Note that I put "non-primitive" in quotes since I'm including `Wrapping`, `Saturating`, and `NonZero`, which are just wrappers over primitives. * `Duration` (arithmetic operations) * `SystemTime` (arithmetic operations) * `Ipv4Addr` (bit operations) * `Ipv6Addr` (bit operations) Additionally, because the methods on `SystemTime` needed to make these operations const were not marked const, a separate tracking issue for const-stabilising those methods is rust-lang#144517. Stuff left out of this PR: * `Assume` (this could trivially be made const, but since the docs indicate this is still under heavy design, I figured I'd leave it out) * `Instant` (this could be made const, but cannot reasonably be constructed at constant time, so, isn't useful) * `SystemTime` (will submit separate PR) * SIMD types (I'm tackling these all at once later; see rust-lang/portable-simd#467) <!-- TRIAGEBOT_START --> <!-- TRIAGEBOT_CONCERN-ISSUE_START --> > [!NOTE] > # Concerns (0 active) > > - ~~[May break Clippy](rust-lang#143949 (comment) resolved in [this comment](rust-lang#143949 (comment)) > > *Managed by ```@rustbot`—see`` [help](https://forge.rust-lang.org/triagebot/concern.html) for details.* <!-- TRIAGEBOT_CONCERN-ISSUE_END --> <!-- TRIAGEBOT_END -->
…=Amanieu document assumptions about `Clone` and `Eq` traits Most standard library collections break if `Clone` has a non-standard implementation which violates `x.clone() == x`. [Here](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b7fc6dfa8410cbb673eb8d38393d81de) the resulting broken behaviour of different collections is shown. I originally created an issue at rust-lang/hashbrown#629, but the conclusion there was that `x.clone()` resulting in an object that compares equal to the original one is probably a very universal assumption. However, this assumption is (to my knowledge) not documented anywhere. I propose to make this assumption explicit in the `Clone` trait documentation. The property that seems the most reasonable to me is the following: When implementing both `Clone` and `PartialEq`, then ```text x == x -> x.clone() == x ``` is expected to hold. This way, when also implementing `Eq`, it automatically follows that `x.clone() == x` has to hold, which should be enough for the collections to not break. At the same time, the property also works for the "normal" elements of a type with `PartialEq`. For the wording, I tried to follow the [`Hash` and `Eq`](https://doc.rust-lang.org/std/hash/trait.Hash.html#hash-and-eq) documentation. As I am fairly new to Rust, it might well be that this property cannot be generally expected – it seems reasonable to me, but any counter-examples or critique, both content- and wording-wise, would be very welcome. If the property turns out to be too general, I would suggest to at least document the assumption of `x.clone() == x` for the collections somehow. An additional thought of mine: If it is indeed generally expected that `x == x -> x.clone() == x`, then, for the sake of completeness, one could also define that `x != x -> y != y for y = x.clone()` should hold, i.e., that an object that did not compare equal to itself before cloning, should also not compare equal to itself afterwards.
…olasbishop std: sys: io: io_slice: Add UEFI types UEFI networking APIs do support vectored read/write. While the types for UDP4, UDP6, TCP4 and TCP6 are defined separately, they are essentially the same C struct. So we can map IoSlice and IoSliceMut to have the same binary representation. Since all UEFI networking types for read/write are DSTs, `IoSlice` and `IoSliceMut` will need to be copied to the end of the transmit/receive structures. So having the same binary representation just allows us to do a single memcpy instead of having to loop and set the DST. cc ``@nicholasbishop``
…htriplett Remove unnecessary parentheses in `assert!`s
Use a time representation with 1900-01-01-00:00:00 at timezone -1440 min as anchor. This is the earliest time supported in UEFI. Signed-off-by: Ayush Singh <[email protected]>
Add tests to ensure that extream system times are still representable. Signed-off-by: Ayush Singh <[email protected]>
This commit amends the documentation of `Vec::as_mut_ptr` and `Vec::into_raw_parts` to make it explicit that such calls may be paired with calls to `dealloc` with a suitable layout. This guarantee was effectively already provided by the docs of `Vec::from_raw_parts` mentioning `alloc`. Additionally, we copy-paste and adjust the “Memory layout” section from the documentation of `std::boxed` to `std::vec`. This explains the allocator guarantees in more detail.
…r=dtolnay Make explicit guarantees about `Vec`’s allocator This commit amends the documentation of `Vec::as_mut_ptr` and `Vec::into_raw_parts` to make it explicit that such calls may be paired with calls to `dealloc` with a suitable layout. This guarantee was effectively already provided by the docs of `Vec::from_raw_parts` mentioning `alloc`. Additionally, we copy-paste and adjust the “Memory layout” section from the documentation of `std::boxed` to `std::vec`. This explains the allocator guarantees in more detail.
Fix a typo in range docs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an automated PR to update the subtree/library branch to the changes from 2025-08-06 (rust-lang/rust@ec7c026) to 2025-08-13 (rust-lang/rust@8e62bfd), inclusive.
Review this PR as usual, but do not merge this PR using the GitHub web interface. Instead, once it is approved, use
git pushto literally push the changes tosubtree/librarywithout any rebase or merge.