| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#145468 (dedup recip, powi, to_degrees, and to_radians float tests)
- rust-lang/rust#145643 (coverage: Build an "expansion tree" and use it to unexpand raw spans)
- rust-lang/rust#145754 (fix(lexer): Don't require frontmatters to be escaped with indented fences)
- rust-lang/rust#146060 (fixup nix dev shell again)
- rust-lang/rust#146068 (compiletest: Capture panic messages via a custom panic hook)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
dedup recip, powi, to_degrees, and to_radians float tests
Deduplicates recip, powi, to_degrees, and to_radians float tests.
I had to fiddle and slightly increase the tolerances for a few comparisons, so maybe not all of the tests are worth deduplicating.
Part of rust-lang/rust#141726.
Best reviewed commit-by-commit.
r? `@tgross35`
|
|
Change std f32 test to pass under Miri
Adds `APPROX_DELTA` to 2 tests of `f32::log` reported in [#miri > Miri test-libstd Failure (2025-08)](https://rust-lang.zulipchat.com/#narrow/channel/269128-miri/topic/Miri.20test-libstd.20Failure.20.282025-08.29).
I changed 2 lines, the first one is the actual failure. The second one is precautionary.
|
|
Add `Bound::copied`
Tracking Issue: https://github.com/rust-lang/rust/issues/145966
Some questions:
- [x] Should I update the documentation for `cloned` to actual used a `Clone` type instead of an integer?
- [x] I removed the `must_use` since this is a cheap copy, does that make sense?
|
|
|
|
std: fix `SplitPaths` regression
Fixes rust-lang/rust#146045 by defining the TAIT more precisely, ensuring that `'a` does not need to be live on drop.
|
|
|
|
|
|
|
|
|
|
Clarify that align_offset overaligns
The current documentation is not clear whether adding `a` to a pointer overaligns (align up) or underaligns (align down).
It should say this explicitly.
cc `@nagisa`
|
|
Fix format string grammar in docs and improve alignment error message for #144023
This PR improves error messages and documentation for format strings involving alignment and formatting traits.
Highlights:
- Clearer error messages for invalid alignment specifiers (e.g., `{0:#X>18}`), showing the expected `<`, `^`, or `>` and a working example:
println!("{0:>#18X}", value);
- Updated UI test `format-alignment-hash.rs` to reflect the improved error output.
- Documentation clarification: ensures examples correctly show how width, alignment, and traits like `x`, `X`, `#` combine.
Motivation:
Previously, using `#` with alignment and width produced confusing errors. This PR guides users on the correct syntax and provides actionable examples.
Testing:
- Built the compiler (`./x build`)
- Blessed and ran UI tests (`./x. test src/test/ui/fmt/format-alignment-hash.rs --bless`)
- Verified full test suite passes (`./x test`)
Issue: rust-lang/rust#144023
|
|
Ensure consistent drop for panicking drop in hint::select_unpredictable
There are a few alternatives to the implementation. The principal problem is that the selected value must be owned (in the sense of having a 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. Unfortunately, that causes LLVM to discard the !unpredictable annotation (for some reason that is beyond my comprehension of LLVM).
<details>
<summary>Extract from the build log showing an unannotated select being used</summary>
```
2025-08-09T16:51:06.8790764Z 39: define noundef i64 `@test_int2(i1` noundef zeroext %p, i64 noundef %a, i64 noundef %b) unnamed_addr #0 personality ptr `@rust_eh_personality` {
2025-08-09T16:51:06.8791368Z check:47'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
2025-08-09T16:51:06.8791700Z 40: start:
2025-08-09T16:51:06.8791858Z check:47'0 ~~~~~~~
2025-08-09T16:51:06.8792043Z 41: %ret.i = select i1 %p, i64 %a, i64 %b
2025-08-09T16:51:06.8792293Z check:47'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2025-08-09T16:51:06.8792686Z check:47'1 ? possible intended match
2025-08-09T16:51:06.8792946Z 42: ret i64 %ret.i
2025-08-09T16:51:06.8793127Z check:47'0 ~~~~~~~~~~~~~~~~
```
</details>
So instead, this PR includes a guard to drop the selected `MaybeUnit<T>` which is active only for the section where the unselected value is dropped. That leaves the code for selecting the result intact leading to the expected ir. That complicates the 'unselection' process a little bit since we require _both_ values as a result of that intrinsic call. Since the arguments alias, this portion as well as the drop guard uses raw pointers.
Closes: rust-lang/rust#145148
Prior: rust-lang/rust#139977
|
|
Make target pointer width in target json an integer
r? Noratrieb
cc `@RalfJung` (https://github.com/rust-lang/rust/pull/142352/files#r2230380120)
try-job: x86_64-rust-for-linux
|
|
|
|
Fix `sys::process::windows::tests::test_thread_handle` spurious failure
Instead of sleeping, wait for the process to finish so that we can be sure it's done. We use a timeout because otherwise this test can be stuck indefinitely if it fails (unfortunately std doesn't currently have a way to wait with a timeout so a manual OS API call is necessary).
I also changed the test to run `whoami` and pipe the output to null so that it doesn't clutter up the test output.
Fixes rust-lang/rust#146024
|
|
std: clarify `OpenOptions` error for create without write access
Fixes rust-lang/rust#140621
|
|
|
|
Hard-code `char::is_control`
Split off from https://github.com/rust-lang/rust/pull/145219
According to
https://www.unicode.org/policies/stability_policy.html#Property_Value, the set of codepoints in `Cc` will never change. So we can hard-code the patterns to match against instead of using a table.
This doesn't change the generated assembly, since the lookup table is small enough that[ LLVM is able to inline the whole search](https://godbolt.org/z/bG8dM37YG). But this does reduce the chance of regressions if LLVM's heuristics change in the future, and means less generated Rust code checked in to `unicode-data.rs`.
|
|
Previously, attempting to create/truncate a file without write/append access
would result in platform-specific error messages:
- Unix: "Invalid argument"
- Windows: raw OS error code 87
These error codes look like system errors, which could waste hours
of debugging for what is actually an API misuse issue.
|
|
I left the additional asserts on {f16, f128}::MAX.recip() in a new
test_max_recip tests.
|
|
|
|
Instead of a tuple, select the dropped value and its guard with two
separate calls to the intrinsic which makes both calls have a
pointer-valued argument that should be simpler in codegen. Use the same
condition on all (not an inverted condition) to clarify the intent of
parallel selection. This should also be a simpler value-dependency chain
if the guard is deduced unused (i.e. drop_in_place a noop for the type).
|
|
|
|
Add Duration::from_nanos_u128
Feature Gate: `#![feature(duration_from_nanos_u128)]`
ACP: https://github.com/rust-lang/libs-team/issues/567
Tracking issue: https://github.com/rust-lang/rust/issues/139201
Recreated from https://github.com/rust-lang/rust/pull/139243
|
|
Optimize `.ilog({2,10})` to `.ilog{2,10}()`
Optimize `.ilog({2,10})` to `.ilog{2,10}()`
Inform compiler of optimizations when the base is known at compile time and there's a cheaper method available:
* `{integer}.checked_ilog(2)` -> `{integer}.checked_ilog2()`
* `{integer}.checked_ilog(10)` -> `{integer}.checked_ilog10()`
* `{integer}.ilog(2)` -> `{integer}.ilog2()`
* `{integer}.ilog(10)` -> `{integer}.ilog10()`
|
|
Stabilize `array_repeat` feature
This closes [tracking issue](https://github.com/rust-lang/rust/issues/126695) and stabilises `array::repeat`
|
|
Implementation: `#[feature(nonpoison_condvar)]`
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
This PR continues the effort made in https://github.com/rust-lang/rust/pull/144022 by adding the implementation of `nonpoison::condvar`.
Many of the changes here are similar to the changes made to implement `nonpoison::mutex`.
There are two other changes here. The first is that the `Barrier` implementation is migrated to use the `nonpoison::Condvar` instead of the `poison` variant. The second (which might be subject to some discussion) is that `WaitTimeoutResult` is moved up to `mod.rs`, as both `condvar` variants need that type (and I do not know if there is a better place to put it now).
### Related PRs
- `nonpoison_rwlock` implementation: https://github.com/rust-lang/rust/pull/144648
- `nonpoison_once` implementation: https://github.com/rust-lang/rust/pull/144653
|
|
fix(lib-std-fs): handle `usize` overflow in `read*`
I assume this is a non-breaking change, as there would be an OOM `panic` anyways. This patch ensures a fast-fail when there's not enough memory to load the file. This only changes behavior on platforms where `usize` is smaller than 64bits
|
|
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>
|
|
|
|
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
|
|
Partial-stabilize the basics from `bigint_helper_methods`
Direct link to p-FCP comment: https://github.com/rust-lang/rust/pull/144494#issuecomment-3133172161
After libs-api discussion, this is now the following methods:
- [`uN::carrying_add`](https://doc.rust-lang.org/nightly/std/primitive.u64.html#method.carrying_add): uN + uN + bool -> (uN, bool)
- [`uN::borrowing_sub`](https://doc.rust-lang.org/nightly/std/primitive.u64.html#method.borrowing_sub): uN + uN + bool -> (uN, bool)
- [`uN::carrying_mul`](https://doc.rust-lang.org/nightly/std/primitive.u64.html#method.carrying_mul): uN * uN + uN -> (uN, uN)
- [`uN::carrying_mul_add`](https://doc.rust-lang.org/nightly/std/primitive.u64.html#method.carrying_mul_add): uN * uN + uN + uN -> (uN, uN)
Specifically, these are the ones that are specifically about working with `uN` as a "digit" (or "limb") where the output, despite being larger than can fit in a single digit, wants to be phrased in terms of those *digits*, not in terms of a wider type.
(This leaves open the possibility of things like `widening_mul: u32 * u32 -> u64` for places where one wants to only think in terms of the *number*s, rather than as carries between multiple digits. Though of course discussions about how best to phrase such a thing are best for the tracking issue, not for this PR.)
---
**Original PR description**:
A [conversation on IRLO](https://internals.rust-lang.org/t/methods-for-splitting-integers-into-their-halves/23210/7?u=scottmcm) the other day pushed me to write this up 🙂
This PR proposes a partial stabilization of `bigint_helper_methods` (rust-lang/rust#85532), focusing on a basic set that hopefully can be non-controversial. Specifically:
- [`uN::carrying_add`](https://doc.rust-lang.org/nightly/std/primitive.u64.html#method.carrying_add): uN + uN + bool -> (uN, bool)
- [`uN::widening_mul`](https://doc.rust-lang.org/nightly/std/primitive.u64.html#method.widening_mul): uN * uN -> (uN, uN)
- [`uN::carrying_mul_add`](https://doc.rust-lang.org/nightly/std/primitive.u64.html#method.carrying_mul_add): uN * uN + uN + uN -> (uN, uN)
Why these?
- We should let people write Rust without needing to be backend experts to know what the magic incantation is to do this. Even `carrying_add`, which doesn't seem that complicated, actually broke in 1.82 (see rust-lang/rust#133674) so we should just offer something fit-for-purpose rather than making people keep up with whatever the secret sauce is today. We also get to do things that users cannot, like have the LLVM version emit operations on `i256` in the implementation of `u128::carrying_mul_add` (https://rust.godbolt.org/z/cjG7eKcxd).
- Unsigned only because the behaviour is much clearer than when signed is involved, as everything is just unsigned (vs questions like whether `iN * iN` should give `(uN, iN)`) and carries can only happen in one direction (vs questions about whether the carry from `-128_u8 + -128_u8` should be considered `-1`).
- `carrying_add` is the core [full adder](https://en.wikipedia.org/wiki/Adder_(electronics)#Full_adder) primitive for implementing addition.
- `carrying_mul_add` is the core primitive for [grade school](https://en.wikipedia.org/wiki/Multiplication_algorithm#Long_multiplication) multiplication (see the example in its docs for why both carries are needed).
- `widening_mul` even though it's not strictly needed (its implementation is just `carrying_mul_add(a, b, 0, 0)` right now) as the simplest way for users to get to [cranelift's `umulhi`](https://docs.rs/cranelift/latest/cranelift/prelude/trait.InstBuilder.html#method.umulhi), RISC-V's `MULHU`, Arm's `UMULL`, etc. (For example, I added an ISLE pattern https://github.com/bytecodealliance/wasmtime/commit/d12e4237de867d58d8c3451d77ee7547e9492550#diff-2041f67049d5ac3d8f62ea91d3cb45cdb8608d5f5cdab988731ae2addf90ef01 so Cranelift can notice what's happening from the fallback, even if the intrinsics aren't overridden specifically. And on x86 this is one of the simplest possible non-trivial functions <https://rust.godbolt.org/z/4oadWKTc1> because `MUL` puts the results in exactly the registers that the scalar pair result happens to want.)
(I did not const-stabilize them in this PR because [the fallbacks](https://github.com/rust-lang/rust/blob/master/library/core/src/intrinsics/fallback.rs) are using `#[const_trait]` plus there's two [new intrinsic](https://doc.rust-lang.org/nightly/std/intrinsics/fn.disjoint_bitor.html)s involved, so I didn't want to *also* open those cans of worms here. Given that both intrinsics *have* fallbacks, and thus don't do anything that can't already be expressed in existing Rust, const-stabilizing these should be straight-forward once the underlying machinery is allowed on stable. But that doesn't need to keep these from being usable at runtime in the mean time.)
|
|
Inform compiler of optimizations when the base is known at compile time
and there's a cheaper method available:
* `{integer}.checked_ilog(2)` -> `{integer}.checked_ilog2()`
* `{integer}.checked_ilog(10)` -> `{integer}.checked_ilog10()`
* `{integer}.ilog(2)` -> `{integer}.ilog2()`
* `{integer}.ilog(10)` -> `{integer}.ilog10()`
|
|
compiler-builtins subtree update
Subtree update of `compiler-builtins` to https://github.com/rust-lang/compiler-builtins/commit/ac3a4cd846be6f3c3a587c7ab79a95084ef75868.
Created using https://github.com/rust-lang/josh-sync.
r? `@ghost`
|
|
Mark pipe2 supported in Android
Android has supported pipe2 since 2010, long before the current min SDK.
|
|
std: haiku: fix `B_FIND_PATH_IMAGE_PATH`
Fixes https://github.com/rust-lang/rust/issues/145952, which was caused by https://github.com/rust-lang/libc/pull/4575
```````@rustbot``````` label T-libs O-haiku
|
|
str: Stabilize `round_char_boundary` feature
Closes https://github.com/rust-lang/rust/issues/93743
FCP completed https://github.com/rust-lang/rust/issues/93743#issuecomment-3168382171
|
|
r=scottmcm
Stabilize `strict_provenance_atomic_ptr` feature
This closes [tracking issue](https://github.com/rust-lang/rust/issues/99108) and stabilises `AtomicPtr::{fetch_ptr_add, fetch_ptr_sub, fetch_byte_add, fetch_byte_sub, fetch_or, fetch_and, fetch_xor}`
---
EDIT: FCP completed at https://github.com/rust-lang/rust/issues/99108#issuecomment-3168260347
|
|
Tracking issue: RUST-139201
Co-authored-by: omanirudh <omanirudh2014@gmail.com>
|
|
|
|
|
|
use `llvm.roundeven` on arm
|
|
It's historically been flaky and is no longer needed now that std_detect
has been moved out of this repository.
|
