simplify the declaration of the legacy integer modules (`std::u32` etc.)
This PR removes some duplicated code from the declaration of the legacy integer modules by expanding the macro which is already used to generate `MIN` and `MAX` to now generate the whole module.
This would also make the remaining steps listed in rust-lang/rust#68490 such as fully deprecating the modules or placing `#[doc(hidden)]` on them easier.
const-eval: disable pointer fragment support
This fixes https://github.com/rust-lang/rust/issues/146291 by disabling pointer fragment support for const-eval. I want to properly fix this eventually, but won't get to it in the next few weeks, so this is an emergency patch to prevent the buggy implementation from landing on stable. The beta cutoff is on Sep 12th so if this PR lands after that, we'll need a backport.
mark `format_args_nl!` as `#[doc(hidden)]`
The `#[unstable]` attribute of the macro already says:
> `format_args_nl` is only for internal language use and is subject to change
It does seem plausible to hide it from the `std` docs accordingly.
The PR also removes the single usage of the macro outside of `std` as it does not seem like the macro is actually needed there.
Implement `Sum` and `Product` for `f16` and `f128`.
Tracking issue: rust-lang/rust#116909.
This PR implements `core::iter::{Sum, Product}` for `f16` and `f128`.
I'm curious as to why these two traits aren't already implemented. I've been unable to find any information about it at all, so if there is anything that currently blocks them, I would appreciate if someone could fill me in.
Fix typo in default.rs
This sentence currently reads:
> Rust implements `Default` for various primitives types.
I think it should just be "primitive types".
The ASCII subset of Unicode is fixed and will never change, so we don't
need to generate tables for it with every new Unicode version. This
saves a few bytes of static data and speeds up `char::is_control` and
`char::is_grapheme_extended` on ASCII inputs.
Since the table lookup functions exported from the `unicode` module will
give nonsensical errors on ASCII input (and in fact will panic in debug
mode), I had to add some private wrapper methods to `char` which check
for ASCII-ness first.
Miri: non-deterministic floating point operations in foreign_items
Take 2 of rust-lang/rust#143906. The last 2 commits are what changed compared to the original pr.
Verified the tests using (fish shell):
```fish
env MIRIFLAGS="-Zmiri-max-extra-rounding-error -Zmiri-many-seeds" ./x miri --no-fail-fast std core coretests -- f32 f64
```
r? `@RalfJung`
single buffer for exponent fmt of integers
No need for fragmented buffers when formatting.
```
orig.txt: fmt::write_i128_exp 143.39ns/iter +/- 0.32
orig.txt: fmt::write_i64_exp 68.72ns/iter +/- 0.03
new.txt: fmt::write_i128_exp 138.29ns/iter +/- 0.50
new.txt: fmt::write_i64_exp 58.93ns/iter +/- 4.62
```
This patch fully eliminates unsafe pointer use (after rust-lang/rust#135265 and rust-lang/rust#136594).
r? libs
Simplify `{f16, f32, f64, f128}::midpoint()`
`(float_ty::MAX / 2) - (float_ty::MIN_POSITIVE * 2)` equals `(float_ty::MAX / 2) + (float_ty::MIN_POSITIVE * 2)` equals `(float_ty::MAX / 2)`. So these branches are pointless.
CC `@Urgau` who wrote the original implementation in https://github.com/rust-lang/rust/pull/92048; does this seem right?
`@rustbot` label A-floating-point
Implement Integer funnel shifts
Tracking issue: rust-lang/rust#145686
ACP: https://github.com/rust-lang/libs-team/issues/642
This implements funnel shifts on primitive integer types. Implements this for cg_llvm, with a fallback impl for everything else
Thanks `@folkertdev` for the fixes and tests
cc `@rust-lang/libs-api`
docs(std): add missing closing code block fences in doc comments
This PR adds a few closing code block fences which I believe are missing in some doc comments. It seems that rustdoc just autocloses code blocks at the end of doc comments and thus these were easily overlooked: I do not think these code blocks are special in any way.
I found these when working on a Clippy lint that checks the last sentence of doc comments for terminal punctuation, and these were failing cases when testing against the std. Therefore I am not entirely sure these are all such cases, but still have high hopes that they are (or at least a well-defined subset of them).
Constify conversion traits (part 1)
This is the first part of rust-lang/rust#144289 being split into smaller pieces. It adds/moves constness of several traits under the `const_convert` feature:
* `From`
* `Into`
* `TryFrom`
* `TryInto`
* `FromStr`
* `AsRef`
* `AsMut`
* `Borrow`
* `BorrowMut`
* `Deref`
* `DerefMut`
There are a few methods that are intrinsically tied to these traits which I've included in the feature. Particularly, those which are wrappers over `AsRef`:
* `ByteStr::new` (unstable under `bstr` feature)
* `OsStr::new`
* `Path::new`
Those which directly use `Into`:
* `Result::into_ok`
* `Result::into_err`
And those which use `Deref` and `DerefMut`:
* `Pin::as_ref`
* `Pin::as_mut`
* `Pin::as_deref_mut`
* `Option::as_deref`
* `Option::as_deref_mut`
* `Result::as_deref`
* `Result::as_deref_mut`
(note: the `Option` and `Result` methods were suggested by ``@npmccallum`` initially as rust-lang/rust#146101)
The parts which are missing from this PR are:
* Anything that involves heap-allocated types
* Making any method const than the ones listed above
* Anything that could rely on the above, *or* could rely on system-specific code for `OsStr` or `Path` (note: this mostly makes these methods useless since `str` doesn't implement `AsRef<OsStr>` yet, but it's better to track the method for now and add impls later, IMHO)
r? ``@tgross35`` (who mostly already reviewed this)
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?
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`
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
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`.
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).
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()`
