| Age | Commit message (Collapse) | Author | Lines |
|---|
|
break_ok/continue_ok
|
|
Stabilize the `cell_update` feature
Included API:
```rust
impl<T: Copy> Cell<T> {
pub fn update(&self, f: impl FnOnce(T) -> T);
}
```
FCP completed once at https://github.com/rust-lang/rust/issues/50186#issuecomment-2198783432 but the signature has since changed.
Closes: https://github.com/rust-lang/rust/issues/50186
|
|
{B,C}Str: minor cleanup
(hopefully) uncontroversial bits extracted from #139994.
|
|
add next_index to Enumerate
Proposal: https://github.com/rust-lang/libs-team/issues/435
Tracking Issue: #130711
This basically just reopens #130682 but squashed and with the new function and the feature gate renamed to `next_index.`
There are two questions I have already:
- Shouldn't we add test coverage for that? I'm happy to provide some, but I might need a pointer to where these test would be.
- Maybe I could actually also add a doctest?
- For now, I just renamed the feature name in the unstable attribute to `next_index`, as well, so it matches the new name of the function. Is that okay? And can I just do that and use any string, or is there a sealed list of features defined somewhere where I also need to change the name?
|
|
Implement `Default` for raw pointers
ACP: https://github.com/rust-lang/libs-team/issues/571
This is instantly stable so we will need an FCP here.
Closes https://github.com/rust-lang/rfcs/issues/2464
|
|
|
|
Implement `pin!()` using `super let`
Tracking issue for super let: https://github.com/rust-lang/rust/issues/139076
This uses `super let` to implement `pin!()`.
This means we can remove [the hack](https://github.com/rust-lang/rust/pull/138717) we had to put in to fix https://github.com/rust-lang/rust/issues/138596.
It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.
While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.
It'd help [the experiment](https://github.com/rust-lang/rust/issues/139076) to have `pin!()` use `super let`, so we can get some more experience with it.
|
|
|
|
This intrinsic doesn't drop the value that is not selected so this is
manually done in the public function that wraps the intrinsic.
|
|
|
|
|
|
Ensure `swap_nonoverlapping` is really always untyped
This replaces #134954, which was arguably overcomplicated.
## Fixes #134713
Actually using the type passed to `ptr::swap_nonoverlapping` for anything other than its size + align turns out to not work, so this goes back to always erasing the types down to just bytes.
(Except in `const`, which keeps doing the same thing as before to preserve `@RalfJung's` fix from #134689)
## Fixes #134946
I'd previously moved the swapping to use auto-vectorization *on bytes*, but someone pointed out on Discord that the tail loop handling from that left a whole bunch of byte-by-byte swapping around. This goes back to manual tail handling to avoid that, then still triggers auto-vectorization on pointer-width values. (So you'll see `<4 x i64>` on `x86-64-v3` for example.)
|
|
|
|
|
|
Following `#135937` and `#136642`, tests for core and alloc are in
coretests and alloctests. Fix tidy to lint for the new paths. Also,
update comments referring to the old locations.
Some context for changes which don't match that pattern:
* library/std/src/thread/local/dynamic_tests.rs and
library/std/src/sync/mpsc/sync_tests.rs were moved under
library/std/tests/ in 332fb7e6f1d (Move std::thread_local unit tests
to integration tests, 2025-01-17) and b8ae372e483 (Move std::sync unit
tests to integration tests, 2025-01-17), respectively, so are no
longer special cases.
* There never was a library/core/tests/fmt.rs file. That comment
previously referred to src/test/ui/ifmt.rs, which was folded into
library/alloc/tests/fmt.rs in 949c96660c3 (move format! interface
tests, 2020-09-08).
|
|
Run coretests and alloctests with cg_clif in CI
Part of https://github.com/rust-lang/rustc_codegen_cranelift/issues/1290
|
|
Included API:
impl<T: Copy> Cell<T> {
pub fn update(&self, f: impl FnOnce(T) -> T);
}
Closes: https://github.com/rust-lang/rust/issues/50186
|
|
|
|
Do the following:
* Switch to `impl FnOnce` rather than a generic `F`.
* Change `update` to return nothing.
This was discussed at a libs-api meeting [1].
Tracking issue: https://github.com/rust-lang/rust/issues/50186
[1]: https://github.com/rust-lang/rust/pull/134446#issuecomment-2770842949
|
|
remove `feature(inline_const_pat)`
Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck.
With https://github.com/rust-lang/types-team/issues/129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now:
- we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types
- we want the inline const pattern to participate in exhaustiveness checking
- to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**.
There are 4 possible ways to handle this:
- stop typechecking inline const patterns together with their parent
- causes inline const patterns to be different than inline const exprs
- prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1`
- region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn
- inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck
- difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing
- do they carry their weight if they are now just equivalent to using an if-guard
- delay exhaustiveness checking until after borrowck
- should be possible in theory, but is a quite involved change and may have some unexpected challenges
- remove this feature for now
I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out.
`const { .. }`-expressions remain stable. These seem to have been the main motivation for https://github.com/rust-lang/rfcs/issues/2920.
r? types
cc `@rust-lang/types` `@rust-lang/lang` #76001
|
|
Co-authored-by: Daniel Henry-Mantilla <daniel.henry.mantilla@gmail.com>
|
|
|
|
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.
|
|
|
|
|
