remove `#[rustc_intrinsic_must_be_overridde]`
In https://github.com/rust-lang/rust/pull/135031, we gained support for just leaving away the body. Now that the bootstrap compiler got bumped, stop using the old style and remove support for it.
r? `@oli-obk`
There are a few more mentions of this attribute in RA code that I didn't touch; Cc `@rust-lang/rust-analyzer`
remove some unnecessary rustc_const_unstable
If the function is anyway unstable, it doesn't need to be `rustc_const_unstable`.
`copy_from_slice` turns out to not do anything const-unstable itself, we just haven't stably committed to it being available in const yet. See [here](https://rustc-dev-guide.rust-lang.org/stability.html?highlight=rustc_const_stable_indirect) for more details on the `rustc_const_stable_indirect` attribute.
Unstable `gen_future` Feature Tracking
This PR removes the reference to the closed tracking issue **#50547** for the `gen_future` feature. Since `gen_future` is an internal feature used in async block desugaring, it does not require a public tracking issue.
#### Changes:
- Replaced `issue = "50547"` with `issue = "none"` in **library/core/src/future/mod.rs**.
- Ensures that it is correctly identified as an internal feature.
#### Rationale:
With this change, the Unstable Book will now state:
> *"This feature has no tracking issue and is therefore likely internal to the compiler, not being intended for general use."*
Closes **#76249**. 🚀🦀
Fixed issue with usage of generics and moved feature gate to crate root
Removed const tag
Fixed alphabetical ordering of feature gate, added same to doctest
Removed crate-level declaration of feature gate control_flow_into_value
Used const_precise_live_drops to constify into_value without issue of a drop
intrinsics: unify rint, roundeven, nearbyint in a single round_ties_even intrinsic
LLVM has three intrinsics here that all do the same thing (when used in the default FP environment). There's no reason Rust needs to copy that historically-grown mess -- let's just have one intrinsic and leave it up to the LLVM backend to decide how to lower that.
Suggested by `@hanna-kruppe` in https://github.com/rust-lang/rust/issues/136459; Cc `@tgross35`
try-job: test-various
Add #[track_caller] to Duration Div impl
Previously the location of the divide-by-zero error condition would be attributed to the code in the rust standard library, eg:
thread 'main' panicked at /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/time.rs:1172:31:
divide by zero error when dividing duration by scalar
With #[track_caller] the error is correctly attributed to the callee.
libcore/net: `IpAddr::as_octets()`
[ACP](https://github.com/rust-lang/libs-team/issues/535)
[Tracking issue](https://github.com/rust-lang/rust/issues/137259)
Adds `const` `core::net::IpAddr{,v4,v6}::as_octets()` methods to provide reference access to IP address contents.
The concrete usecase for me is allowing the `IpAddr` to provide an extended lifetime in contexts that want a `&[u8]`:
```rust
trait AddrSlice {
fn addr_slice(&self) -> &[u8];
}
impl AddrSlice for IpAddrV4 {
fn addr_slice(&self) -> &[u8] {
// self.octets() doesn't help us here, because we can't return a reference to the owned array.
// Instead we want the IpAddrV4 to continue owning the memory:
self.as_octets()
}
}
```
(Notably, in this case we can't parameterize `AddrSlice` by a `const N: usize` (such that `fn addr_slice(&self) -> [u8; N]`) and maintain object-safety.)
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
Use more explicit and reliable ptr select in sort impls
Using `if ...` with the intent to avoid branches can be surprising to readers and carries the risk of turning into jumps/branches generated by some future compiler version, breaking crucial optimizations.
This commit replaces their usage with the explicit and IR annotated `bool::select_unpredictable`.
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.
Adds `const` `Ip*Addr::as_octets` methods providing reference access to
`Ip*Addr` octets contents.
See https://github.com/rust-lang/libs-team/issues/535 for accepted ACP
with a more detailed justification.
fix docs for inherent str constructors
related to #131114
when implementing inherent str constructors in #136517, i forgot to change the docs, so the code examples still imported the `std::str` module and used the constructor from there, instead of using "itself" (the inherent constructor).
Make ub_check message clear that it's not an assert
I've seen a user assume that their unsound code was *safe*, because ub_check prevented the program from performing the unsafe operation.
This PR makes the panic message clearer that ub_check is a bug detector, not run-time safety protection.
Previously the location of the divide-by-zero error condition would be
attributed to the code in the rust standard library, eg:
thread 'main' panicked at /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/time.rs:1172:31:
divide by zero error when dividing duration by scalar
With #[track_caller] the error is correctly attributed to the callee.
Apply unsafe_op_in_unsafe_fn to the standard library
This applies unsafe_op_in_unsafe_fn to the standard library in preparation for updating to Rust 2024.
Closes https://github.com/rust-lang/rust/issues/127747 (I think?) cc ``@workingjubilee``
I have been testing a variety of targets, and I feel like they are all pretty much covered. I'll continue doing some testing async, but I don't expect to catch any more.
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>
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 `const_is_char_boundary` and `const_str_split_at`.
Tracking issues: #131516, #131518
Stabilized const API:
```rs
// in `core`
impl str {
// const_is_char_boundary feature
const fn is_char_boundary(&self, index: usize) -> bool;
// const_str_split_at feature, depends on const_is_char_boundary
const fn split_at(&self, mid: usize) -> (&str, &str);
const fn split_at_mut(&mut self, mid: usize) -> (&mut str, &mut str);
const fn split_at_checked(&self, mid: usize) -> Option<(&str, &str)>;
const fn split_at_mut_checked(&mut self, mid: usize) -> Option<(&mut str, &mut str)>;
}
```
This will allow safely splitting string slices during const-eval.
Closes#131516, Closes#131518
This will need FCP.
r? libs-api
IIUC these do not use any new const language features (i.e. they are implementable manually on stable 1.83.0 using `unsafe`: [playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3679632cd1041084796241b7ac8edfbd)).
Cc ``@rust-lang/wg-const-eval`` (I don't know if I have the permissions for this ping; if not, someone else please ping wg-const-eval if it is necessary)
Remove the common prelude module
This fixes the issues described in https://github.com/rust-lang/rust/issues/136102. Primarily, this resolves some issues with how the documentation for the prelude is generated:
- It avoids showing "unstable" for macros in the prelude that are actually stable.
- Avoids duplication of some pages due to the previous lack of `doc(no_inline)`.
- Makes the different edition preludes consistent, and sets a pattern that can be used by future editions.
We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
Closes https://github.com/rust-lang/rust/issues/136102
`transmute` should also assume non-null pointers
Previously it only did integer-ABI things, but this way it does data pointers too. That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.
Use a trait to enforce field validity for union fields + `unsafe` fields + `unsafe<>` binder types
This PR introduces a new, internal-only trait called `BikeshedGuaranteedNoDrop`[^1] to faithfully model the field check that used to be implemented manually by `allowed_union_or_unsafe_field`.
942db6782f/compiler/rustc_hir_analysis/src/check/check.rs (L84-L115)
Copying over the doc comment from the trait:
```rust
/// Marker trait for the types that are allowed in union fields, unsafe fields,
/// and unsafe binder types.
///
/// Implemented for:
/// * `&T`, `&mut T` for all `T`,
/// * `ManuallyDrop<T>` for all `T`,
/// * tuples and arrays whose elements implement `BikeshedGuaranteedNoDrop`,
/// * or otherwise, all types that are `Copy`.
///
/// Notably, this doesn't include all trivially-destructible types for semver
/// reasons.
///
/// Bikeshed name for now.
```
As far as I am aware, there's no new behavior being guaranteed by this trait, since it operates the same as the manually implemented check. We could easily rip out this trait and go back to using the manually implemented check for union fields, however using a trait means that this code can be shared by WF for `unsafe<>` binders too. See the last commit.
The only diagnostic changes are that this now fires false-negatives for fields that are ill-formed. I don't consider that to be much of a problem though.
r? oli-obk
[^1]: Please let's not bikeshed this name lol. There's no good name for `ValidForUnsafeFieldsUnsafeBindersAndUnionFields`.
Previously it only did integer-ABI things, but this way it does data pointers too. That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.
Stabilize target_feature_11
# Stabilization report
This is an updated version of https://github.com/rust-lang/rust/pull/116114, which is itself a redo of https://github.com/rust-lang/rust/pull/99767. Most of this commit and report were copied from those PRs. Thanks ```@LeSeulArtichaut``` and ```@calebzulawski!```
## Summary
Allows for safe functions to be marked with `#[target_feature]` attributes.
Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot *generally* be assigned to safe function pointers, and don't implement the `Fn*` traits.
However, calling them from other `#[target_feature]` functions with a superset of features is safe.
```rust
// Demonstration function
#[target_feature(enable = "avx2")]
fn avx2() {}
fn foo() {
// Calling `avx2` here is unsafe, as we must ensure
// that AVX is available first.
unsafe {
avx2();
}
}
#[target_feature(enable = "avx2")]
fn bar() {
// Calling `avx2` here is safe.
avx2();
}
```
Moreover, once https://github.com/rust-lang/rust/pull/135504 is merged, they can be converted to safe function pointers in a context in which calling them is safe:
```rust
// Demonstration function
#[target_feature(enable = "avx2")]
fn avx2() {}
fn foo() -> fn() {
// Converting `avx2` to fn() is a compilation error here.
avx2
}
#[target_feature(enable = "avx2")]
fn bar() -> fn() {
// `avx2` coerces to fn() here
avx2
}
```
See the section "Closures" below for justification of this behaviour.
## Test cases
Tests for this feature can be found in [`tests/ui/target_feature/`](f6cb952dc1/tests/ui/target-feature).
## Edge cases
### Closures
* [target-feature 1.1: should closures inherit target-feature annotations? #73631](https://github.com/rust-lang/rust/issues/73631)
Closures defined inside functions marked with #[target_feature] inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits.
```rust
#[target_feature(enable = "avx2")]
fn qux() {
let my_closure = || avx2(); // this call to `avx2` is safe
let f: fn() = my_closure;
}
```
This means that in order to call a function with #[target_feature], you must guarantee that the target-feature is available while the function, any closures defined inside it, as well as any safe function pointers obtained from target-feature functions inside it, execute.
This is usually ensured because target features are assumed to never disappear, and:
- on any unsafe call to a `#[target_feature]` function, presence of the target feature is guaranteed by the programmer through the safety requirements of the unsafe call.
- on any safe call, this is guaranteed recursively by the caller.
If you work in an environment where target features can be disabled, it is your responsibility to ensure that no code inside a target feature function (including inside a closure) runs after this (until the feature is enabled again).
**Note:** this has an effect on existing code, as nowadays closures do not inherit features from the enclosing function, and thus this strengthens a safety requirement. It was originally proposed in #73631 to solve this by adding a new type of UB: “taking a target feature away from your process after having run code that uses that target feature is UB” .
This was motivated by userspace code already assuming in a few places that CPU features never disappear from a program during execution (see i.e. 2e29bdf908/crates/std_detect/src/detect/arch/x86.rs); however, concerns were raised in the context of the Linux kernel; thus, we propose to relax that requirement to "causing the set of usable features to be reduced is unsafe; when doing so, the programmer is required to ensure that no closures or safe fn pointers that use removed features are still in scope".
* [Fix #[inline(always)] on closures with target feature 1.1 #111836](https://github.com/rust-lang/rust/pull/111836)
Closures accept `#[inline(always)]`, even within functions marked with `#[target_feature]`. Since these attributes conflict, `#[inline(always)]` wins out to maintain compatibility.
### ABI concerns
* [The extern "C" ABI of SIMD vector types depends on target features #116558](https://github.com/rust-lang/rust/issues/116558)
The ABI of some types can change when compiling a function with different target features. This could have introduced unsoundness with target_feature_11, but recent fixes (#133102, #132173) either make those situations invalid or make the ABI no longer dependent on features. Thus, those issues should no longer occur.
### Special functions
The `#[target_feature]` attribute is forbidden from a variety of special functions, such as main, current and future lang items (e.g. `#[start]`, `#[panic_handler]`), safe default trait implementations and safe trait methods.
This was not disallowed at the time of the first stabilization PR for target_features_11, and resulted in the following issues/PRs:
* [`#[target_feature]` is allowed on `main` #108645](https://github.com/rust-lang/rust/issues/108645)
* [`#[target_feature]` is allowed on default implementations #108646](https://github.com/rust-lang/rust/issues/108646)
* [#[target_feature] is allowed on #[panic_handler] with target_feature 1.1 #109411](https://github.com/rust-lang/rust/issues/109411)
* [Prevent using `#[target_feature]` on lang item functions #115910](https://github.com/rust-lang/rust/pull/115910)
## Documentation
* Reference: [Document the `target_feature_11` feature reference#1181](https://github.com/rust-lang/reference/pull/1181)
---
cc tracking issue https://github.com/rust-lang/rust/issues/69098
cc ```@workingjubilee```
cc ```@RalfJung```
r? ```@rust-lang/lang```
Change swap_nonoverlapping from lang to library UB
The implementation of ptr::swap_nonoverlapping does not always escalate its safety contract to language UB, so it should be `check_library_ub`.
Fixes https://github.com/rust-lang/miri/issues/4188
Change the issue number for `likely_unlikely` and `cold_path`
These currently point to rust-lang/rust#26179, which is nearly a decade old and has a lot of outdated discussion. Move these features to a new tracking issue specifically for the recently added API.
New tracking issue: https://github.com/rust-lang/rust/issues/136873
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 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`.
This fixes the issues described in
https://github.com/rust-lang/rust/issues/136102. Primarily, this
resolves some issues with how the documentation for the prelude is
generated:
- It avoids showing "unstable" for macros in the prelude that are
actually stable.
- Avoids duplication of some pages due to the previous lack of
`doc(no_inline)`.
- Makes the different edition preludes consistent, and sets a pattern
that can be used by future editions.
We may need to rearrange these modules in the future if we decide to
remove anything from the prelude again. If we do, I think we should look
into a different solution that avoids the documentation problems.
Introduce CoercePointeeWellformed for coherence checks at typeck stage
Fix#135206
This is the first PR to introduce the "wellformedness" check for `derive(CoercePointee)`.
This patch introduces a new error code to cover all the prerequisites of the said macro. The checks that is enforced with this patch is whether the data is indeed `struct` and whether the layout is set to `repr(transparent)`.
A following series of patch will arrive later to address the following concern.
1. #135217 so that we would only admit one single coercion on one type parameter, and leave the rest for future consideration in tandem of development of other coercion rules.
1. Enforcement of data field requirements.
**An open question** is whether there is a good schema to encode the `#[pointee]` as well, so that we could also check if the `#[pointee]` type parameter is indeed `?Sized`.
``@rustbot`` label F-derive_coerce_pointee
Some miscellaneous edition-related library tweaks
Some library edition tweaks that can be done separately from upgrading the whole standard library to edition 2024 (which is blocked on getting the submodules upgraded, for example)
Update bootstrap compiler and rustfmt
The rustfmt version we previously used formats things differently from what the latest nightly rustfmt does. This causes issues for subtrees that get formatted both in-tree and in their own repo. Updating the rustfmt used in-tree solves those issues. Also bumped the bootstrap compiler as the stage0 update command always updates both at the same
time.
Rollup of 5 pull requests
Successful merges:
- #134679 (Windows: remove readonly files)
- #136213 (Allow Rust to use a number of libc filesystem calls)
- #136530 (Implement `x perf` directly in bootstrap)
- #136601 (Detect (non-raw) borrows of null ZST pointers in CheckNull)
- #136659 (Pick the max DWARF version when LTO'ing modules with different versions )
r? `@ghost`
`@rustbot` modify labels: rollup
Make `AsyncFnOnce`, `AsyncFnMut`, `AsyncFn` non-`#[fundamental]`
Address the issue #136723 on nightly (the issue will only *actually* be fixed with a beta backport).
Because the neutral element of `<fNN as iter::Sum>` was changed to
`neg_zero`, the documentation needed to be updated, as it was reporting
inadequate information about what should be expected from the return.
Co-authored-by: Jubilee <workingjubilee@gmail.com>
Using if ... with the intent to avoid branches can be surprising to readers and
carries the risk of turning into jumps/branches generated by some future
compiler version, breaking crucial optimizations.
This commit replaces their usage with the explicit and IR annotated
`bool::select_unpredictable`.
Rename `slice::take...` methods to `split_off...`
This rename was discussed and recommended in a recent t-libs meeting.
cc https://github.com/rust-lang/rust/issues/62280
There's an additional commit here which modifies internals of unstable `OneSidedRange` APIs in order to implement `split_off` methods in a panic-free way (remove `unreachable!()`) as recommended in https://github.com/rust-lang/rust/pull/88502/files#r760177240. I can split this out into a separate PR if needed.
implement inherent str constructors
implement #131114
this implements
- str::from_utf8
- str::from_utf8_mut
- str::from_utf8_unchecked
- str::from_utf8_unchecked_mut
i left `std::str::from_raw_parts` and `std::str::from_raw_parts_mut` out of this as those are unstable and were not mentioned by the tracking issue or the original pull request, but i can add those here as well.
i was also unsure of what to do with the `rustc_const_(un)stable` attributes: i removed the `#[rustc_const_stable]` attribute from `str::from_utf8`, `str::from_utf8_unchecked` and `str::from_utf8_unchecked_mut`, and left the`#[rust_const_unstable]` in `str::from_utf8_mut` (btw why is that one not const stable yet with #57349 merged?).
is there a way to redirect users to the stable `std::str::from_utf8` instead of only saying "hey this is unstable"?
for now i just removed the check for `str::from_utf8` in the test in `tests/ui/suggestions/suggest-std-when-using-type.rs`.
Mark `std::fmt::from_fn` as `#[must_use]`
While working on #135494 I managed to shoot my own foot a few times by forgetting to actually use the result of `fmt::from_fn`, so I think a `#[must_use]` could be appropriate!
Didn't have a good message to put in the attr so left it blank, still unstable so we can come back to it I guess?
cc #117729 (and a huge +1 for getting it stabilized, it's very useful IMHO)
#[contracts::requires(...)] + #[contracts::ensures(...)]
cc https://github.com/rust-lang/rust/issues/128044
Updated contract support: attribute syntax for preconditions and postconditions, implemented via a series of desugarings that culminates in:
1. a compile-time flag (`-Z contract-checks`) that, similar to `-Z ub-checks`, attempts to ensure that the decision of enabling/disabling contract checks is delayed until the end user program is compiled,
2. invocations of lang-items that handle invoking the precondition, building a checker for the post-condition, and invoking that post-condition checker at the return sites for the function, and
3. intrinsics for the actual evaluation of pre- and post-condition predicates that third-party verification tools can intercept and reinterpret for their own purposes (e.g. creating shims of behavior that abstract away the function body and replace it solely with the pre- and post-conditions).
Known issues:
* My original intent, as described in the MCP (https://github.com/rust-lang/compiler-team/issues/759) was to have a rustc-prefixed attribute namespace (like rustc_contracts::requires). But I could not get things working when I tried to do rewriting via a rustc-prefixed builtin attribute-macro. So for now it is called `contracts::requires`.
* Our attribute macro machinery does not provide direct support for attribute arguments that are parsed like rust expressions. I spent some time trying to add that (e.g. something that would parse the attribute arguments as an AST while treating the remainder of the items as a token-tree), but its too big a lift for me to undertake. So instead I hacked in something approximating that goal, by semi-trivially desugaring the token-tree attribute contents into internal AST constucts. This may be too fragile for the long-term.
* (In particular, it *definitely* breaks when you try to add a contract to a function like this: `fn foo1(x: i32) -> S<{ 23 }> { ... }`, because its token-tree based search for where to inject the internal AST constructs cannot immediately see that the `{ 23 }` is within a generics list. I think we can live for this for the short-term, i.e. land the work, and continue working on it while in parallel adding a new attribute variant that takes a token-tree attribute alongside an AST annotation, which would completely resolve the issue here.)
* the *intent* of `-Z contract-checks` is that it behaves like `-Z ub-checks`, in that we do not prematurely commit to including or excluding the contract evaluation in upstream crates (most notably, `core` and `std`). But the current test suite does not actually *check* that this is the case. Ideally the test suite would be extended with a multi-crate test that explores the matrix of enabling/disabling contracts on both the upstream lib and final ("leaf") bin crates.
Rollup of 5 pull requests
Successful merges:
- #134777 (Enable more tests on Windows)
- #135621 (Move some std tests to integration tests)
- #135844 ( Add new tool for dumping feature status based on tidy )
- #136167 (Implement unstable `new_range` feature)
- #136334 (Extract `core::ffi` primitives to a separate (internal) module)
Failed merges:
- #136201 (Removed dependency on the field-offset crate, alternate approach)
r? `@ghost`
`@rustbot` modify labels: rollup
Add `cast_signed` and `cast_unsigned` methods for `NonZero` types
Requested in https://github.com/rust-lang/rust/issues/125882 .
Note that this keeps the same names as the methods currently present on other
integer types. If we want to rename them, we can rename them all at the same
time.
Extract `core::ffi` primitives to a separate (internal) module
### Introduce library/core/src/ffi/primitives.rs
The regex preprocessing for PR #133944 would be more robust if the relevant types from core/src/ffi/mod.rs were first moved to library/core/src/ffi/primitives.rs, then there isn't a need to deal with traits / c_str / va_list / whatever might wind up in that module in the future
r? `@tgross35`
Implement unstable `new_range` feature
Switches `a..b`, `a..`, and `a..=b` to resolve to the new range types.
For rust-lang/rfcs#3550
Tracking issue #123741
also adds the re-export that was missed in the original implementation of `new_range_api`
Display of integers without raw pointers and without overflowing_literals
The benchmarks as is measure formatting speed of literals. The first commit `black_box`-es input to simulate runtime speed instead.
The second commit replaces `unsafe` pointer optimizations with plain array indices. The performance is equivalent on Apple M1. Needs peer review on Intel.
Happy to do the 128-bit version too if such change is welcome.
This has now been approved as a language feature and no longer needs
a `rustc_` prefix.
Also change the `contracts` feature to be marked as incomplete and
`contracts_internals` as internal.
1. Document the new intrinsics.
2. Make the intrinsics actually check the contract if enabled, and
remove `contract::check_requires` function.
3. Use panic with no unwind in case contract is using to check for
safety, we probably don't want to unwind. Following the same
reasoning as UB checks.
The extended syntax for function signature that includes contract clauses
should never be user exposed versus the interface we want to ship
externally eventually.
includes post-developed commit: do not suggest internal-only keywords as corrections to parse failures.
includes post-developed commit: removed tabs that creeped in into rustfmt tool source code.
includes post-developed commit, placating rustfmt self dogfooding.
includes post-developed commit: add backquotes to prevent markdown checking from trying to treat an attr as a markdown hyperlink/
includes post-developed commit: fix lowering to keep contracts from being erroneously inherited by nested bodies (like closures).
Rebase Conflicts:
- compiler/rustc_parse/src/parser/diagnostics.rs
- compiler/rustc_parse/src/parser/item.rs
- compiler/rustc_span/src/hygiene.rs
Remove contracts keywords from diagnostic messages
There was a macro parameter giving signed impls access to the
corresponding unsigned type, but not the other way around.
This will allow implementing methods converting in both directions.
rustc_allowed_through_unstable_modules: require deprecation message
This changes the `#[rustc_allowed_through_unstable_modules]` attribute so that a deprecation message (ideally directing people towards the stable path) is required.
Implement all mix/max functions in a (hopefully) more optimization amendable way
Previously the graph was like this:
```
min -> Ord::min -> min_by -> match on compare() (in these cases compare = Ord::cmp)
^
|
min_by_key
```
now it looks like this:
```
min -> Ord::min -> `<=` <- min_by_key
min_by -> `Ordering::is_le` of `compare()`
```
(`max*` and `minmax*` are the exact same, i.e. they also use `<=` and `is_le`)
I'm not sure how to test this, but it should probably be easier for the backend to optimize.
r? `@scottmcm`
cc https://github.com/rust-lang/rust/issues/115939#issuecomment-2622161134
Insert null checks for pointer dereferences when debug assertions are enabled
Similar to how the alignment is already checked, this adds a check
for null pointer dereferences in debug mode. It is implemented similarly
to the alignment check as a `MirPass`.
This inserts checks in the same places as the `CheckAlignment` pass and additionally
also inserts checks for `Borrows`, so code like
```rust
let ptr: *const u32 = std::ptr::null();
let val: &u32 = unsafe { &*ptr };
```
will have a check inserted on dereference. This is done because null references
are UB. The alignment check doesn't cover these places, because in `&(*ptr).field`,
the exact requirement is that the final reference must be aligned. This is something to
consider further enhancements of the alignment check.
For now this is implemented as a separate `MirPass`, to make it easy to disable
this check if necessary.
This is related to a 2025H1 project goal for better UB checks in debug
mode: https://github.com/rust-lang/rust-project-goals/pull/177.
r? `@saethlin`
Similar to how the alignment is already checked, this adds a check
for null pointer dereferences in debug mode. It is implemented similarly
to the alignment check as a MirPass.
This is related to a 2025H1 project goal for better UB checks in debug
mode: https://github.com/rust-lang/rust-project-goals/pull/177.
float::min/max: mention the non-determinism around signed 0
Turns out this can actually produce different results on different machines [in practice](https://github.com/rust-lang/rust/issues/83984#issuecomment-2623859230); that seems worth documenting. I assume LLVM will happily const-fold these operations so so there could be different results for the same input even on the same machine, depending on whether things get const-folded or not.
`@nikic` I remember there was an LLVM soundness fix regarding scalar evolution for loops that had to recognize certain operations as non-deterministic... it seems to me that pass would also have to avoid predicting the result of `llvm.{min,max}num`, for the same reason?
r? `@tgross35`
Cc `@rust-lang/libs-api`
If this lands we should also make Miri non-deterministic here.
Fixes https://github.com/rust-lang/rust/issues/83984
Stabilize `const_black_box`
This has been unstably const since #92226, but a tracking issue was never created. Per [discussion on Zulip][zulip], there should not be any blockers to making this const-stable. The function does not provide any functionality at compile time but does allow code reuse between const- and non-const functions, so stabilize it here.
[zulip]: https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const_black_box
Remove minor future footgun in `impl Debug for MaybeUninit`
No longer breaks if `MaybeUninit` moves modules (technically it could break if `MaybeUninit` were renamed but realistically that will never happen)
Debug impl originally added in #133282
Add `AsyncFn*` to `core` prelude
In https://github.com/rust-lang/rust/pull/132611 these got added to the `std` prelude only, which looks like an oversight.
r? libs-api
cc `@compiler-errors`
Implement `int_from_ascii` (#134821)
Provides unstable `T::from_ascii()` and `T::from_ascii_radix()` for integer types `T`, as drafted in tracking issue #134821.
To deduplicate documentation without additional macros, implementations of `isize` and `usize` no longer delegate to equivalent integer types. After #132870 they are inlined anyway.
Cleanup docs for Allocator
This is an attempt to remove ungrammatical constructions and clean up the prose. I've sometimes had to try hard to understand what was being stated, so it is possible that I've misunderstood the original meaning. In particular, I did not see a difference between:
- the borrow-checker lifetime of the allocator type itself.
- as long as at least one of the allocator instance and all of its clones has not been dropped.
optimize slice::ptr_rotate for small rotates
r? `@scottmcm`
This swaps the positions and numberings of algorithms 1 and 2 in `slice::ptr_rotate`, and pulls the entire outer loop into algorithm 3 since it was redundant for the first two. Effectively, `ptr_rotate` now always does the `memcpy`+`memmove`+`memcpy` sequence if the shifts fit into the stack buffer.
With this change, an `IndexMap`-style `move_index` function is optimized correctly.
Assembly comparisons:
- `move_index`, before: https://godbolt.org/z/Kr616KnYM
- `move_index`, after: https://godbolt.org/z/1aoov6j8h
- the code from `#89714`, before: https://godbolt.org/z/Y4zaPxEG6
- the code from `#89714`, after: https://godbolt.org/z/1dPx83axc
related to #89714
some relevant discussion in https://internals.rust-lang.org/t/idea-shift-move-to-efficiently-move-elements-in-a-vec/22184
Behavior tests pass locally. I can't get any consistent microbenchmark results on my machine, but the assembly diffs look promising.
