| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Stabilize `unbounded_shifts`
This stabilizes and const-stabilizes `<iN>::unbounded_shl` and `<uN>::unbounded_shr` from https://github.com/rust-lang/rust/issues/129375.
|
|
Master bootstrap update
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday
r? `@Mark-Simulacrum`
|
|
r=Noratrieb
stabilize `unsigned_is_multiple_of`
tracking issue: https://github.com/rust-lang/rust/issues/128101
fcp completed in: https://github.com/rust-lang/rust/issues/128101#issuecomment-2674880635
### Public API
A version of this for all the unsigned types
```rust
fn is_multiple_of(lhs: u64, rhs: u64) -> bool {
match rhs {
// prevent division by zero
0 => lhs == 0,
_ => lhs % rhs == 0,
}
}
```
|
|
Implement feature `isolate_most_least_significant_one` for integer types
Accepted ACP - https://github.com/rust-lang/libs-team/issues/467
Tracking issue - #136909
Implement ACP for functions that isolate the most significant set bit and least significant set bit on unsigned, signed, and `NonZero` integers.
Add function `isolate_most_significant_one`
Add function `isolate_least_significant_one`
---
This PR adds the following impls
```rust
impl {u8, u16, u32, u64, u128, usize} {
const fn isolate_most_significant_one(self) -> Self;
const fn isolate_least_significant_one(self) -> Self;
}
impl {i8, i16, i32, i64, i128, isize} {
const fn isolate_most_significant_one(self) -> Self;
const fn isolate_least_significant_one(self) -> Self;
}
impl NonZeroT {
const fn isolate_most_significant_one(self) -> Self;
const fn isolate_least_significant_one(self) -> Self;
}
```
Example behavior
```rust
assert_eq!(u8::isolate_most_significant_one(0b01100100), 0b01000000);
assert_eq!(u8::isolate_least_significant_one(0b01100100), 0b00000100);
```
|
|
|
|
Optionally add type names to `TypeId`s.
This feature is intended to provide expensive but thorough help for developers who have an unexpected `TypeId` value and need to determine what type it actually is. It causes `impl Debug for TypeId` to print the type name in addition to the opaque ID hash, and in order to do so, adds a name field to `TypeId`. The cost of this is the increased size of `TypeId` and the need to store type names in the binary; therefore, it is an optional feature. It does not expose any new public API, only change the `Debug` implementation.
It may be enabled via `cargo -Zbuild-std -Zbuild-std-features=debug_typeid`. (Note that `-Zbuild-std-features` disables default features which you may wish to reenable in addition; see
<https://doc.rust-lang.org/cargo/reference/unstable.html#build-std-features>.)
Example usage and output:
```
fn main() {
use std::any::{Any, TypeId};
dbg!(TypeId::of::<usize>(), drop::<usize>.type_id());
}
```
```
TypeId::of::<usize>() = TypeId(0x763d199bccd319899208909ed1a860c6 = usize)
drop::<usize>.type_id() = TypeId(0xe6a34bd13f8c92dd47806da07b8cca9a = core::mem::drop<usize>)
```
Also added feature declarations for the existing `debug_refcell` feature so it is usable from the `rust.std-features` option of `config.toml`.
Related issues:
* #68379
* #61533
|
|
|
|
|
|
Stabilize `num_midpoint_signed` feature
This PR proposes that we stabilize the signed variants of [`iN::midpoint`](https://github.com/rust-lang/rust/issues/110840#issue-1684506201), the operation is equivalent to doing `(a + b) / 2` in a sufficiently large number.
The stabilized API surface would be:
```rust
/// Calculates the middle point of `self` and `rhs`.
///
/// `midpoint(a, b)` is `(a + b) / 2` as if it were performed in a
/// sufficiently-large signed integer type. This implies that the result is
/// always rounded towards zero and that no overflow will ever occur.
impl i{8,16,32,64,128,size} {
pub const fn midpoint(self, rhs: Self) -> Self;
}
```
T-libs-api previously stabilized the unsigned (and float) variants in #131784, the signed variants were left out because of the rounding that should be used in case of negative midpoint.
This stabilization proposal proposes that we round towards zero because:
- it makes the obvious `(a + b) / 2` in a sufficiently-large number always true
- using another rounding for the positive result would be inconsistent with the unsigned variants
- it makes `midpoint(-a, -b)` == `-midpoint(a, b)` always true
- it is consistent with `midpoint(a as f64, b as f64) as i64`
- it makes it possible to always suggest `midpoint` as a replacement for `(a + b) / 2` expressions *(which we may want to do as a future work given the 21.2k hits on [GitHub Search](https://github.com/search?q=lang%3Arust+%2F%5C%28%5Ba-zA-Z_%5D*+%5C%2B+%5Ba-zA-Z_%5D*%5C%29+%5C%2F+2%2F&type=code&p=1))*
`@scottmcm` mentioned a drawback in https://github.com/rust-lang/rust/pull/132191#issuecomment-2439891200:
> I'm torn, because rounding towards zero makes it "wider" than other values, which `>> 1` avoids -- `(a + b) >> 1` has the nice behaviour that `midpoint(a, b) + 2 == midpoint(a + 2, b + 2)`.
>
> But I guess overall sticking with `(a + b) / 2` makes sense as well, and I do like the negation property 🤷
Which I think is outweigh by the advantages cited above.
Closes #110840
cc `@rust-lang/libs-api`
cc `@scottmcm`
r? `@dtolnay`
|
|
Implement accepted ACP for functions that isolate the most significant
set bit and least significant set bit on unsigned, signed, and NonZero
integers.
Add function `isolate_most_significant_one`
Add function `isolate_least_significant_one`
Add tests
|
|
Add `MAX_LEN_UTF8` and `MAX_LEN_UTF16` Constants
This pull request adds the `MAX_LEN_UTF8` and `MAX_LEN_UTF16` constants as per #45795, gated behind the `char_max_len` feature.
The constants are currently applied in the `alloc`, `core` and `std` libraries.
|
|
|
|
|
|
Make Rust pointers less magic by including metadata information in their
`Debug` output.
This does not break Rust stability guarantees because `Debug` output is
explicitly exempted from stability:
https://doc.rust-lang.org/std/fmt/trait.Debug.html#stability
Co-authored-by: Lukas <26522220+lukas-code@users.noreply.github.com>
Co-authored-by: Josh Stone <cuviper@gmail.com>
|
|
|
|
Because `.as_ptr()` changes the type of the pointer (e.g. `&[u8]`
becomes `*const u8` instead of `*const [u8]`), and it can't be expected
that different types will be formatted the same way.
|
|
Implement Extend<AsciiChar> for String
Implement `Extend<AsciiChar>` for `String` as suggested in https://github.com/rust-lang/rust/issues/110998#issuecomment-2590122968. Also implements `Extend<&AsciiChar>` since there's an analogous impl for `Extend<&char>`, but happy to remove if not thought useful.
r? `@scottmcm`
since you requested it, but no pressure to review!
|
|
Prepare standard library for Rust 2024 migration
This includes a variety of commits preparing the standard library for migration to Rust 2024.
The actual migration is blocked on a few things, so I wanted to get this out of the way in a relatively digestable PR.
|
|
|
|
Stabilize `get_many_mut` as `get_disjoint_mut`
Tracking issue: #104642
Closes #104642
FCP completed in https://github.com/rust-lang/rust/issues/104642#issuecomment-2558161073
|
|
|
|
This feature is intended to provide expensive but thorough help for
developers who have an unexpected `TypeId` value and need to determine
what type it actually is. It causes `impl Debug for TypeId` to print
the type name in addition to the opaque ID hash, and in order to do so,
adds a name field to `TypeId`. The cost of this is the increased size of
`TypeId` and the need to store type names in the binary; therefore, it
is an optional feature.
It may be enabled via `cargo -Zbuild-std -Zbuild-std-features=debug_typeid`.
(Note that `-Zbuild-std-features` disables default features which you
may wish to reenable in addition; see
<https://doc.rust-lang.org/cargo/reference/unstable.html#build-std-features>.)
Example usage and output:
```
fn main() {
use std::any::{Any, TypeId};
dbg!(TypeId::of::<usize>(), drop::<usize>.type_id());
}
```
```
TypeId::of::<usize>() = TypeId(0x763d199bccd319899208909ed1a860c6 = usize)
drop::<usize>.type_id() = TypeId(0xe6a34bd13f8c92dd47806da07b8cca9a = core::mem::drop<usize>)
```
Also added feature declarations for the existing `debug_refcell` feature
so it is usable from the `rust.std-features` option of `config.toml`.
|
|
Some miscellaneous edition-related library tweaks
Some library edition tweaks that can be done separately from upgrading the whole standard library to edition 2024 (which is blocked on getting the submodules upgraded, for example)
|
|
|
|
|
|
|
|
Remove some unnecessary parens in `assert!` conditions
While working on #122661, some of these started triggering our "unnecessary parens" lints due to a change in the `assert!` desugaring. A cursory search identified a few more. Some of these have been carried from before 1.0, were a bulk rename from the previous name of `assert!` left them in that state. I went and removed as many of these unnecessary parens as possible in order to have fewer annoyances in the future if we make the lint smarter.
|
|
|
|
While working on #122661, some of these started triggering our "unnecessary parens" lints due to a change in the `assert!` desugaring. A cursory search identified a few more. Some of these have been carried from before 1.0, were a bulk rename from the previous name of `assert!` left them in that state. I went and removed as many of these unnecessary parens as possible in order to have fewer annoyances in the future if we make the lint smarter.
|
|
|
|
Display of integers without raw pointers and without overflowing_literals
The benchmarks as is measure formatting speed of literals. The first commit `black_box`-es input to simulate runtime speed instead.
The second commit replaces `unsafe` pointer optimizations with plain array indices. The performance is equivalent on Apple M1. Needs peer review on Intel.
Happy to do the 128-bit version too if such change is welcome.
|
|
|
|
* Renames the methods:
* `get_many_mut` -> `get_disjoint_mut`
* `get_many_unchecked_mut` -> `get_disjoint_unchecked_mut`
* Does not rename the feature flag: `get_many_mut`
* Marks the feature as stable
* Renames some helper stuff:
* `GetManyMutError` -> `GetDisjointMutError`
* `GetManyMutIndex` -> `GetDisjointMutIndex`
* `get_many_mut_helpers` -> `get_disjoint_mut_helpers`
* `get_many_check_valid` -> `get_disjoint_check_valid`
This only touches slice methods.
HashMap's methods and feature gates are not renamed here
(nor are they stabilized).
|
|
|
|
This has been unstably const since [1], but a tracking issue was never
created. Per discussion on Zulip [2], there should not be any blockers
to making this const-stable. The function does not provide any
functionality at compile time but does allow code reuse between const-
and non-const functions, so stabilize it here.
[1]: https://github.com/rust-lang/rust/pull/92226
[2]: https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const_black_box
|
|
It previously didn't get run because of a missing mod bstr.
|
|
|
