| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Recognise new IPv6 non-global range from IETF RFC 9602
This PR adds the `5f00::/16` range defined by [IETF RFC 9602](https://datatracker.ietf.org/doc/rfc9602/) to those ranges which `Ipv6Addr::is_global` recognises as a non-global IP. This range is used for Segment Routing (SRv6) SIDs.
See also: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
Unstable tracking issue: #27709
|
|
Reduce FormattingOptions to 64 bits
This is part of https://github.com/rust-lang/rust/issues/99012
This reduces FormattingOptions from 6-7 machine words (384 bits on 64-bit platforms, 224 bits on 32-bit platforms) to just 64 bits (a single register on 64-bit platforms).
Before:
```rust
pub struct FormattingOptions {
flags: u32, // only 6 bits used
fill: char,
align: Option<Alignment>,
width: Option<usize>,
precision: Option<usize>,
}
```
After:
```rust
pub struct FormattingOptions {
/// Bits:
/// - 0-20: fill character (21 bits, a full `char`)
/// - 21: `+` flag
/// - 22: `-` flag
/// - 23: `#` flag
/// - 24: `0` flag
/// - 25: `x?` flag
/// - 26: `X?` flag
/// - 27: Width flag (if set, the width field below is used)
/// - 28: Precision flag (if set, the precision field below is used)
/// - 29-30: Alignment (0: Left, 1: Right, 2: Center, 3: Unknown)
/// - 31: Always set to 1
flags: u32,
/// Width if width flag above is set. Otherwise, always 0.
width: u16,
/// Precision if precision flag above is set. Otherwise, always 0.
precision: u16,
}
```
|
|
|
|
Add an attribute that makes the spans from a macro edition 2021, and fix pin on edition 2024 with it
Fixes a regression, see issue below. This is a temporary fix, super let is the real solution.
Closes #138596
|
|
This commit adds the 5f00::/16 range defined by RFC9602 to those ranges which Ipv6Addr::is_global recognises as a non-global IP. This range is used for Segment Routing (SRv6) SIDs.
|
|
|
|
|
|
|
|
`MaybeUninit` inherent slice methods part 2
These were moved out of #129259 since they require additional libs-api approval. Tracking issue: #117428.
New API surface:
```rust
impl<T> [MaybeUninit<T>] {
// replacing fill; renamed to avoid conflict
pub fn write_filled(&mut self, value: T) -> &mut [T] where T: Clone;
// replacing fill_with; renamed to avoid conflict
pub fn write_with<F>(&mut self, value: F) -> &mut [T] where F: FnMut() -> T;
// renamed to remove "fill" terminology, since this is closer to the write_*_of_slice methods
pub fn write_iter<I>(&mut self, iter: I) -> (&mut [T], &mut Self) where I: Iterator<Item = T>;
}
```
Relevant motivation for these methods; see #129259 for earlier methods' motiviations.
* I chose `write_filled` since `filled` is being used as an object here, whereas it's being used as an action in `fill`.
* I chose `write_with` instead of `write_filled_with` since it's shorter and still matches well.
* I chose `write_iter` because it feels completely different from the fill methods, and still has the intent clear.
In all of the methods, it felt appropriate to ensure that they contained `write` to clarify that they are effectively just special ways of doing `MaybeUninit::write` for each element of a slice.
Tracking issue: https://github.com/rust-lang/rust/issues/117428
r? libs-api
|
|
It is only used by a single test, yet would take up unnecessary space
once stdlib deps get vendored.
|
|
core: Make `Debug` impl of raw pointers print metadata if present
Make Rust pointers appear less magic by including metadata information in their `Debug` output.
This does not break Rust stability guarantees because `Debug` impl are explicitly exempted from stability:
https://doc.rust-lang.org/std/fmt/trait.Debug.html#stability
> ## Stability
>
> Derived `Debug` formats are not stable, and so may change with future Rust versions. Additionally, `Debug` implementations of types provided by the standard library (`std`, `core`, `alloc`, etc.) are not stable, and may also change with future Rust versions.
Note that a regression test is added as a separate commit to make it clear what impact the last commit has on the output.
Closes #128684 because the output of that code now becomes:
```
thread 'main' panicked at src/main.rs:5:5:
assertion `left == right` failed
left: Pointer { addr: 0x7ffd45c6fc6b, metadata: 5 }
right: Pointer { addr: 0x7ffd45c6fc6b, metadata: 3 }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
|
|
|
|
|
|
|
|
library: Use `size_of` from the prelude instead of imported
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the prelude instead of importing or qualifying them.
These functions were added to all preludes in Rust 1.80.
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-msvc-1
|
|
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the
prelude instead of importing or qualifying them.
These functions were added to all preludes in Rust 1.80.
|
|
Remove unsizing coercions for tuples
See https://github.com/rust-lang/rust/issues/42877#issuecomment-2686010847 and below comments for justification.
Tracking issue: #42877
Fixes: #135217
|
|
Various coretests improvements
The first commit is not yet strictly necessary as directly testing libcore works though useless work, but will be necessary once https://github.com/rust-lang/rust/pull/136642 migrates the liballoc tests into a separate package. The second commit fixes https://github.com/rust-lang/rust/issues/137478 and ensures that coretests actually gets tested on all CI job. The third commit fixes an error that didn't get caught because coretests doesn't run on the wasm32 CI job.
|
|
dec2flt: Clean up float parsing modules
This is the first portion of my work adding support for parsing and printing `f16`. Changes in `float.rs` replace the magic constants with expressions and add some use of generics to better support the new float types. Everything else is related to documentation or naming; there are no functional changes in this PR.
This can be reviewed by commit.
|
|
Stabilize [T]::split_off... methods
This was previously known as the slice_take feature.
Closes #62280
|
|
A lot of the magic constants can be turned into expressions. This
reduces some code duplication.
Additionally, add traits to make these operations fully generic. This
will make it easier to support `f16` and `f128`.
|
|
|
|
The previous commit renamed `Decimal` to `DecimalSeq`. Now, rename the
type that represents a decimal floating point number to be `Decimal`.
Additionally, add some tests for internal behavior.
|
|
This module currently contains two decimal types, `Decimal` and
`Number`. These names don't provide a whole lot of insight into what
exactly they are, and `Number` is actually the one that is more like an
expected `Decimal` type.
In accordance with this, rename the existing `Decimal` to `DecimalSeq`.
This highlights that it contains a sequence of decimal digits, rather
than representing a base-10 floating point (decimal) number.
Additionally, add some tests to validate internal behavior.
|
|
This was previously known as the slice_take feature.
|
|
|
|
|
|
|
|
|
|
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
|
