| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This seem to have been overlooked in <https://github.com/rust-lang/rust/pull/138162>
|
|
|
|
|
|
Signed-off-by: Sacha Ayoun <sachaayoun@gmail.com>
|
|
Without any tests/benchmarks that show some improvement, it's hard to
know whether the change had any positive effect at all. (And if it did,
whether that effect is still achieved today.)
|
|
|
|
Fix a typo in range docs
|
|
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.
|
|
|
|
|
|
This is a documentation-only deprecation for now.
Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to
compatibility)
Longer term, we expect test runners, like `cargo test`, to provide the
necessary mechanisms for environmental or persistent configuration (e.g.
using cargo config which supports `.cargo/config.toml` as well as
environment variables).
This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)
The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to
implement
- Reduce the mechanisms that test runners, like `cargo test`, are
expected to track when they are being bypassed to protect against
negative interactions, e.g. `RUST_TEST_NOCAPTURE=1` when json output
is being read.
|
|
|
|
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.
|
|
|
|
I was just looking at the specifics of how the parsing is handled here
and I wasn't sure if the examples were incomplete or the grammar below was
misleading.
The grammar was correct so I figured I'd add these examples to clarify.
|
|
Add tests to ensure that extream system times are still representable.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
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 <ayush@beagleboard.org>
|
|
Remove unnecessary parentheses in `assert!`s
|
|
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``
|
|
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 https://github.com/rust-lang/hashbrown/issues/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.
|
|
Constify remaining traits/impls for `const_ops`
Tracking issue: rust-lang/rust#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/rust#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](https://github.com/rust-lang/rust/pull/143949#issuecomment-3081466077)~~ resolved in [this comment](https://github.com/rust-lang/rust/pull/143949#issuecomment-3083628215)
>
> *Managed by ```@rustbot`—see`` [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*
<!-- TRIAGEBOT_CONCERN-ISSUE_END -->
<!-- TRIAGEBOT_END -->
|
|
When operating on expressions, `cfg_select!` can now handle expressions
without braces. (It still requires braces for other things, such as
items.)
Expand the test coverage and documentation accordingly.
|
|
|
|
|
|
|
|
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!).
|
|
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 https://github.com/rust-lang/rust-clippy/issues/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.
|
|
r=ChrisDenton
Stabilize `duration_constructors_lite` feature
This closes [tracking issue](https://github.com/rust-lang/rust/issues/140881) and stabilises `Duration::from_hours` and `Duration::from_mins` while not touching a `duration_constructors` feature from the related [tracking issue (2)](https://github.com/rust-lang/rust/issues/120301)
|
|
|
|
explicitly
|
|
compiler & tools dependencies:
Locking 18 packages to latest compatible versions
Updating anstream v0.6.19 -> v0.6.20
Updating anstyle-query v1.1.3 -> v1.1.4
Updating anstyle-svg v0.1.9 -> v0.1.10
Updating anstyle-wincon v3.0.9 -> v3.0.10
Updating camino v1.1.10 -> v1.1.11
Updating clap v4.5.42 -> v4.5.43
Updating clap_builder v4.5.42 -> v4.5.43
Updating cxx v1.0.161 -> v1.0.166
Updating cxx-build v1.0.161 -> v1.0.166
Updating cxxbridge-cmd v1.0.161 -> v1.0.166
Updating cxxbridge-flags v1.0.161 -> v1.0.166
Updating cxxbridge-macro v1.0.161 -> v1.0.166
Updating derive-where v1.5.0 -> v1.6.0
Updating hashbrown v0.15.4 -> v0.15.5
Updating indenter v0.3.3 -> v0.3.4
Updating rustversion v1.0.21 -> v1.0.22
Updating scratch v1.0.8 -> v1.0.9
Updating zerovec v0.11.2 -> v0.11.4
note: pass `--verbose` to see 36 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating hashbrown v0.15.4 -> v0.15.5
note: pass `--verbose` to see 2 unchanged dependencies behind latest
rustbook dependencies:
Locking 10 packages to latest compatible versions
Updating anstream v0.6.19 -> v0.6.20
Updating anstyle-query v1.1.3 -> v1.1.4
Updating anstyle-wincon v3.0.9 -> v3.0.10
Updating cc v1.2.31 -> v1.2.32
Updating clap v4.5.42 -> v4.5.43
Updating clap_builder v4.5.42 -> v4.5.43
Updating clap_complete v4.5.55 -> v4.5.56
Updating hashbrown v0.15.4 -> v0.15.5
Updating rustversion v1.0.21 -> v1.0.22
Updating zerovec v0.11.2 -> v0.11.4
|
|
elsewhere
`typos.toml` has an exception for "numer", to avoid flagging its use as
an abbreviation for "numerator". Remove the use of that abbrevation,
spelling out "numerator" instead, and remove the exception, so that typo
checks can find future instances of "numer" as a typo for "number".
|
|
LLVM does not currently emit these, but it is being discussed as an
option on platforms where `f32` is not hardware supported. Glibc/libgcc
also has the comparison functions [1] already.
The generic implementations for addition, subtraction, and
multiplication work for f16 without any complications, as do
comparisons, so add them here.
[1]: https://sourceware.org/git/?p=glibc.git;a=commit;h=6ec6c77867af4ddfec7323e0ac6ede89effca852
|
|
Like `__real@`, and `__xmm@`, Windows can emit duplicate `__ymm@`
symbols for constants.
|
|
It seems important for LLVM that we select on the values by-value
instead of reading and have no intermediate store. So make sure the
guards selects both potential drops but defers the return value to the
second selection. Since the two options alias we use raw mutable
pointers instead of mutable references as before.
|
|
|
|
|
|
There are a few alternatives to the implementation. The principal
problem is that the selected value must be owned (in the sense of having
any drop flag of sorts) when the unselected value is dropped, such that
panic unwind goes through the drop of both. This ownership must then be
passed on in return when the drop went smoothly. The basic way of
achieving this is by extracting the selected value first, at the cost of
relying on the optimizer a little more for detecting the copy as
constructing the return value despite having a place in the body.
|
|
|
|
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.
|
|
Adds tests for the `nonpoison::RwLock` variant by using a macro to
duplicate the existing `poison` tests.
Note that all of the tests here are adapted from the existing `poison`
tests.
|
|
This commit simply helps discern the actual changes needed to test both
poison and nonpoison `rwlock`s.
|
|
Adds the equivalent `nonpoison` types to the `poison::rwlock` module.
These types and implementations are gated under the `nonpoison_rwlock`
feature gate.
Also blesses the ui tests that now have a name conflicts (because these
types no longer have unique names). The full path distinguishes the
different types.
|
|
This commit is a purely cosmetic change to the documentation and
ordering of items in the `rwlock.rs` file, which will help discern the
actual difference between the `nonpoison` and `poison` variants of
`rwlock`.
List of changes (lots of small things):
- Clean up some of the existing field doc comments
- Add documentation for every field in struct definitions
- Consolidate related implementation blocks (1 implementation block per
guard instead of 2)
- Use the lifetime name `'rwlock` instead of `'a`
- Reorder implementation blocks to be consistent across the entire file
(follows the order `ReadGuard`, `WriteGuard`, `MappedReadGuard`,
MappedWriteGuard`)
- Move simple trait implementations to the bottom of the file
- Rename the `poison` field in `MappedRwLockWriteGuard` to
posion_guard`
- Cut off comments at 100 columns
- Update the documentation of `downgrade` to match stabilization PR #
143191
|
|
|
|
Fix wasm target build with atomics feature
Introduced by https://github.com/rust-lang/rust/pull/115746
close https://github.com/rust-lang/rust/issues/145101
|
|
Optimize `char::is_alphanumeric`
Avoid an unnecessary call to `unicode::Alphabetic` when `self` is an ASCII digit (ie `0..=9`).
|
|
Move several more float tests to floats/mod.rs
This PR moves several tests to `floats/mod.rs`, as discussed in https://github.com/rust-lang/rust/issues/141726. The tests moved are:
* `test_abs`
* `test_signum`
* `test_is_sign_positive`
* `test_is_sign_negative`
* `test_next_up`
* `test_next_down`
* `test_sqrt_domain`
* `test_clamp_min_greater_than_max`
* `test_clamp_min_is_nan`
* `test_clamp_max_is_nan`
* `test_total_cmp`
This covers all the "easy" tests: the ones that don't have a lot of precision-specific constants. It's not clear to me that it's worth migrating the others.
Each test is its own commit (with the exception of the clamp tests), so it may be easiest to review each commit individually.
r? tgross35
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: ffb9d94dcf4ade0d534842be3672d5e9f47e1333
Filtered ref: 2f31646593733abae36e4c05b5a54acfb9f1f6bc
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to ffb9d94dcf4ade0d534842be3672d5e9f47e1333.
|
