e350a56cf9
move features into the correct section
2026-03-17 09:31:03 +00:00
78157ddde9
Replace version placeholders with 1.95.0
...
(cherry picked from commit bad24ccbec
2026-03-07 10:42:01 -08:00
7b428597ff
add field representing types
2026-02-27 15:54:20 +01:00
14d29f9ae2
Stabilize cfg_select
2026-02-22 19:59:25 +01:00
e0cb264b81
Auto merge of #141295 - Kivooeo:if-let-guard-stable, r=fee1-dead,est31
...
Stabilize `if let` guards (`feature(if_let_guard)`)
## Summary
This proposes the stabilization of `if let` guards (tracking issue: rust-lang/rust#51114 , RFC: rust-lang/rfcs#2294 ). This feature allows `if let` expressions to be used directly within match arm guards, enabling conditional pattern matching within guard clauses.
## What is being stabilized
The ability to use `if let` expressions within match arm guards.
Example:
```rust
enum Command {
Run(String),
Stop,
Pause,
}
fn process_command(cmd: Command, state: &mut String) {
match cmd {
Command::Run(name) if let Some(first_char) = name.chars().next() && first_char.is_ascii_alphabetic() => {
// Both `name` and `first_char` are available here
println!("Running command: {} (starts with '{}')", name, first_char);
state.push_str(&format!("Running {}", name));
}
Command::Run(name) => {
println!("Cannot run command '{}'. Invalid name.", name);
}
Command::Stop if state.contains("running") => {
println!("Stopping current process.");
state.clear();
}
_ => {
println!("Unhandled command or state.");
}
}
}
```
## Motivation
The primary motivation for `if let` guards is to reduce nesting and improve readability when conditional logic depends on pattern matching. Without this feature, such logic requires nested `if let` statements within match arms:
```rust
// Without if let guards
match value {
Some(x) => {
if let Ok(y) = compute(x) {
// Both `x` and `y` are available here
println!("{}, {}", x, y);
}
}
_ => {}
}
// With if let guards
match value {
Some(x) if let Ok(y) = compute(x) => {
// Both `x` and `y` are available here
println!("{}, {}", x, y);
}
_ => {}
}
```
## Implementation and Testing
The feature has been implemented and tested comprehensively across different scenarios:
### Core Functionality Tests
**Scoping and variable binding:**
- [`scope.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs ) - Verifies that bindings created in `if let` guards are properly scoped and available in match arms
- [`shadowing.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs ) - Tests that variable shadowing works correctly within guards
- [`scoping-consistency.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/scoping-consistency.rs ) - Ensures temporaries in guards remain valid for the duration of their match arms
**Type system integration:**
- [`type-inference.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/type-inference.rs ) - Confirms type inference works correctly in `if let` guards
- [`typeck.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/typeck.rs ) - Verifies type mismatches are caught appropriately
**Pattern matching semantics:**
- [`exhaustive.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/exhaustive.rs ) - Validates that `if let` guards are correctly handled in exhaustiveness analysis
- [`move-guard-if-let.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let.rs ) and [`move-guard-if-let-chain.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs ) - Test that conditional moves in guards are tracked correctly by the borrow checker
### Error Handling and Diagnostics
- [`warns.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/warns.rs ) - Tests warnings for irrefutable patterns and unreachable code in guards
- [`parens.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs ) - Ensures parentheses around `let` expressions are properly rejected
- [`macro-expanded.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs ) - Verifies macro expansions that produce invalid constructs are caught
- [`guard-mutability-2.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/guard-mutability-2.rs ) - Tests mutability and ownership violations in guards
- [`ast-validate-guards.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs ) - Validates AST-level syntax restrictions
### Drop Order and Temporaries
**Key insight:** Unlike `let_chains` in regular `if` expressions, `if let` guards do not have drop order inconsistencies because:
1. Match guards are clearly scoped to their arms
2. There is no "else block" equivalent that could cause temporal confusion
- [`drop-order.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/drop-order.rs ) - Check drop order of temporaries create in match guards
- [`compare-drop-order.rs`](https://github.com/rust-lang/rust/blob/aef3f5fdf052fbbc16e174aef5da6d50832ca316/tests/ui/rfcs/rfc-2294-if-let-guard/compare-drop-order.rs ) - Compares drop order between `if let` guards and nested `if let` in match arms, confirming they behave identically across all editions
- rust-lang/rust#140981 - A complicated drop order test involved `let chain` was made by @est31
- [`drop-order-comparisons-let-chains.rs`](https://github.com/rust-lang/rust/blob/902b4d28783e03e231d8513082cc30c4fcce5d95/tests/ui/drop/drop-order-comparisons-let-chains.rs ) - Compares drop order between `let chains` in `if let guard` and regular `if` expressions
- [`if-let-guards.rs`](https://github.com/rust-lang/rust/blob/5650d716e0589e2e145ce9027f35bd534e5f862a/tests/ui/drop/if-let-guards.rs ) - Test correctness of drop order for bindings and temporaries
- [`if-let-guards-2`](https://github.com/rust-lang/rust/blob/3a6c8c8f3d7ae654fdb6ce1255182bda21680655/tests/ui/drop/if-let-guards-2.rs ) - The same test as above but more comprehensive and tests more interactions between different features and their drop order, checking that drop order is correct, created by @traviscross
## Edition Compatibility
This feature stabilizes on all editions, unlike `let chains` which was limited to edition 2024. This is safe because:
1. `if let` guards don't suffer from the drop order issues that affected `let chains` in regular `if` expressions
2. The scoping is unambiguous - guards are clearly tied to their match arms
3. Extensive testing confirms identical behavior across all editions
## Interactions with Future Features
The lang team has reviewed potential interactions with planned "guard patterns" and determined that stabilizing `if let` guards now does not create obstacles for future work. The scoping and evaluation semantics established here align with what guard patterns will need.
## Unresolved Issues
- [x] - rust-lang/rust#140981
- [x] - added tests description by @jieyouxu request
- [x] - Concers from @scottmcm about stabilizing this across all editions
- [x] - check if drop order in all edition when using `let chains` inside `if let` guard is the same
- [x] - interactions with guard patters
- [x] - pattern bindings drops before guard bindings https://github.com/rust-lang/rust/pull/143376
- [x] - documentaion (https://github.com/rust-lang/reference/pull/1957 )
- [ ] (non-blocking) add tests for [this](https://github.com/rust-lang/rust/issues/145237 ) and [this](https://github.com/rust-lang/rust/pull/141295#issuecomment-3173059821 )
---
**Related:**
- Tracking Issue: rust-lang/rust#51114
- RFC: rust-lang/rfcs#2294
- Documentation PR: https://github.com/rust-lang/reference/pull/1957
2026-02-18 20:49:50 +00:00
964b63f42e
if let guard stabilize
2026-02-16 12:24:15 +00:00
b935f379b4
implement carryless_mul
2026-02-14 21:23:30 +01:00
2f3b952349
Stabilize assert_matches
2026-02-11 14:13:44 +01:00
59868c1394
Fix uninitialized UEFI globals in tests
...
Export globals via a `doc(hidden)` module. In test code, use the globals
from `realstd` so that they are properly initialized.
2026-02-01 23:48:27 -05:00
fdad66a382
enable target_feature_inline_always in core and std
...
this is required for compiling `stdarch`
2026-01-26 23:17:31 +01:00
cc666ba8f4
Rollup merge of #149869 - joboet:torn-dbg, r=Mark-Simulacrum
...
std: avoid tearing `dbg!` prints
Fixes https://github.com/rust-lang/rust/issues/136703 .
This is an alternative to rust-lang/rust#149859 . Instead of formatting everything into a string, this PR makes multi-expression `dbg!` expand into multiple nested matches, with the final match containing a single `eprint!`. By using macro recursion and relying on hygiene, this allows naming every bound value in that `eprint!`.
CC @orlp
r? libs
2026-01-25 07:42:58 +01:00
58be5d6620
Move assert_matches to planned stable path
2026-01-21 23:17:24 +01:00
bed40af305
std: avoid tearing dbg! prints
2026-01-21 19:20:04 +01:00
f1922ffe3b
Rollup merge of #151004 - apple-sleep-until, r=ChrisDenton
...
std: implement `sleep_until` on Apple platforms
On Apple platforms, `nanosleep` is internally [implemented](https://github.com/apple-oss-distributions/Libc/blob/55b54c0a0c37b3b24393b42b90a4c561d6c606b1/gen/nanosleep.c#L281 ) using `mach_wait_until`, a function that waits until a deadline specified in terms of `mach_absolute_time`. Since `mach_wait_until` is [public](https://github.com/apple-oss-distributions/xnu/blob/f6217f891ac0bb64f3d375211650a4c1ff8ca1ea/osfmk/mach/mach_time.h#L50-L51 )[^1], we can use it to implement `sleep_until` by converting `Instant`s (which are measured against `CLOCK_UPTIME_RAW`, which is equivalent to `mach_absolute_time`) into `mach_absolute_time` values.
Related tracking issue: https://github.com/rust-lang/rust/issues/113752
[^1]: It's badly documented, but it's defined in the same header as `mach_absolute_time`, which `std` used to use for `Instant` before rust-lang/rust#116238 .
2026-01-19 20:53:21 +01:00
959be82eff
std: implement sleep_until on Apple platforms
2026-01-13 11:22:50 +01:00
e212560317
Stabilize alloc_layout_extra
2026-01-11 16:39:18 +03:00
ae09be5968
std: unify sys::pal::common and sys_common into sys::helpers
2026-01-02 18:23:39 +01:00
1c2dbcf33b
Rollup merge of #150016 - usamoi:stabilize-lazy-get, r=jhpratt
...
stabilize `lazy_get`
closes https://github.com/rust-lang/rust/issues/129333
FCP is finished in https://github.com/rust-lang/rust/issues/129333#issuecomment-3477510482
```@rustbot``` modify labels: +T-libs-api
2025-12-24 02:52:58 -05:00
7b92feb0df
Rollup merge of #149812 - tisonkun:oncelock-const-default, r=Mark-Simulacrum
...
Add const default for OnceCell and OnceLock
cc rust-lang/rust#143894
2025-12-21 18:50:41 +01:00
90a33f69f4
replace version placeholder
2025-12-19 15:04:30 -08:00
141342c34f
stabilize lazy_get
2025-12-15 18:57:33 +08:00
26ae47502a
Rollup merge of #148052 - tgross35:stabilize-const_mul_add, r=RalfJung
...
Stabilize `const_mul_add`
Newly stable API:
```rust
impl {f32, f64} {
pub const fn mul_add(self, a: Self, b: Self) -> Self;
}
```
This includes making the intrinsics `fmaf{16,32,64,128}` const stable for indirect use, matching similar intrinsics.
Closes: https://github.com/rust-lang/rust/issues/146724
2025-12-10 17:16:46 +01:00
df38e1521d
Add const default for OnceCell and OnceLock
...
Signed-off-by: tison <wander4096@gmail.com >
2025-12-09 20:38:47 +08:00
5f3dc5d89a
Rollup merge of #149102 - bend-n:maybe_uninit_slice, r=joboet
...
stabilize maybe_uninit_slice
Tracking issue: rust-lang/rust#63569
Closes : rust-lang/rust#63569
FCP completed: https://github.com/rust-lang/rust/issues/63569#issuecomment-3477510504
Removes:
```rs
pub const fn slice_as_ptr(this: &[MaybeUninit<T>]) -> *const T;
pub const fn slice_as_mut_ptr(this: &mut [MaybeUninit<T>]) -> *mut T;
```
2025-12-01 17:55:06 +01:00
f15e99b2f0
Remove outdated comment
2025-11-27 20:05:58 +02:00
d67f99af2e
fix
2025-11-27 17:55:34 +07:00
a32d3103d5
Rollup merge of #148048 - thaliaarchi:stabilize-maybeuninit-write-slice, r=Mark-Simulacrum
...
Stabilize `maybe_uninit_write_slice`
Stabilize feature `maybe_uninit_write_slice` (closes https://github.com/rust-lang/rust/issues/79995 ).
Note that this also const-stabilizes `<[MaybeUninit<_>]>::write_copy_of_slice`. That method depends on `<[_]>::copy_from_slice`, which is already const-stable, and `<[MaybeUninit<_>]>::assume_init_mut` which is now also stable.
2025-11-27 12:36:48 +11:00
9e497b6071
Add Box::(try_)clone_from_ref(_in)
2025-11-19 13:34:00 -06:00
5dd82e8ed9
Rollup merge of #145610 - GrigorenkoPV:char_max_len, r=Amanieu
...
Stabilize `char_max_len`
Tracking issue: rust-lang/rust#121714
r? t-libs-api
`@rustbot` label +needs-fcp -T-libs +T-libs-api
Closes rust-lang/rust#121714
2025-11-17 18:07:31 +01:00
ec2f7397ce
Rollup merge of #148827 - GoldsteinE:stabilize-vec-into-raw-parts, r=Mark-Simulacrum
...
Stabilize vec_into_raw_parts
This stabilizes `Vec::into_raw_parts()` and `String::into_raw_parts()` per FCP in https://github.com/rust-lang/rust/issues/65816#issuecomment-3517630971 . While this _does not_ stabilize `Vec::into_parts()`, I fixed up the examples that said they were waiting for `vec_into_raw_parts`. As `Vec::from_parts()` and `Vec::into_parts()` are covered by the same feature `box_vec_non_null`, any doctest that uses `Vec::from_parts()` can also use `Vec::into_parts()` (and same for allocator-aware versions).
Closes rust-lang/rust#65816
``@rustbot`` modify labels: +T-libs-api
2025-11-16 14:39:58 +11:00
f9dcc6b21c
Stabilize char_max_len
2025-11-14 18:23:19 +03:00
65b5d765bc
Implement Read::read_array
...
Tracking issue: https://github.com/rust-lang/rust/issues/148848
2025-11-11 16:18:50 -08:00
ac9bb13267
Stabilize vec_into_raw_parts
2025-11-11 20:24:29 +03:00
c59298da36
stabilize stdarch_s390x_feature_detection
2025-11-06 12:49:46 +01:00
033711ce8d
Stabilize const_mul_add
...
Newly stable API:
impl {f32, f64} {
pub const fn mul_add(self, a: Self, b: Self) -> Self;
}
This includes making the intrinsics `fmaf{16,32,64,128}` const stable
for indirect use, matching similar intrinsics.
Closes: https://github.com/rust-lang/rust/issues/146724
2025-10-23 17:10:59 -04:00
5088b3816b
Stabilize maybe_uninit_write_slice
2025-10-23 14:02:41 -06:00
c01682ebf6
Revert "feat: implement hash_map! macro"
...
This reverts commit 066023e47c
2025-10-23 12:37:53 -07:00
18d1b69c92
fix missing link to std::char in std docs
2025-10-14 10:23:29 +02:00
0bc6945186
give a better example why std modules named like primitives are needed
2025-10-05 13:58:11 +02:00
0fd939658e
Rollup merge of #146788 - sysrex:146756/discord_invite, r=workingjubilee
...
chore: removes deprecated discord.
This PR just changes the wording of the contributing document to remove the deprecated Discord.
Fixes https://github.com/rust-lang/rust/issues/146756 .
2025-09-28 09:15:24 +02:00
254a2139f6
Remove cfg(bootstrap) for doc_cfg feature following #141925
2025-09-27 11:29:49 +02:00
ec00723ba1
Fix autodiff feature activation
2025-09-27 11:29:49 +02:00
a7ed9bf6c7
fmt
2025-09-27 11:29:49 +02:00
fccba2c341
Remove doc_cfg_hide feature
2025-09-27 11:29:49 +02:00
63aefe0737
Strenghten checks for doc(auto_cfg(show/hide)) attributes
2025-09-27 11:29:48 +02:00
7c00bccd3b
Implement RFC 3631
2025-09-27 11:29:48 +02:00
a00f24116e
unstably constify float mul_add methods
...
Co-authored-by: Ralf Jung <post@ralfj.de >
2025-09-24 15:21:31 -04:00
8e37f0f120
chore: remove discord references from the std library as well
2025-09-24 09:13:08 +01:00
7a5819d154
Rollup merge of #144091 - thaliaarchi:stabilize-new-zeroed, r=Mark-Simulacrum
...
Stabilize `new_zeroed_alloc`
The corresponding `new_uninit` and `new_uninit_slice` functions were stabilized in rust-lang/rust#129401 , but the zeroed counterparts were left for later out of a [desire](https://github.com/rust-lang/rust/issues/63291#issuecomment-2161039756 ) to stabilize only the minimal set. These functions are straightforward mirrors of the uninit functions and well-established. Since no blockers or design questions have surfaced in the past year, I think it's time to stabilize them.
Tracking issue: rust-lang/rust#129396
2025-09-21 14:42:33 +10:00
5d8e41b656
Revert "Constify SystemTime methods"
...
This reverts commit 7ce620dd7c
2025-09-12 17:16:38 +02:00
cyrgani