[core/fmt] Replace checked slice indexing by unchecked to support panic-free code
Fixes#126425
Replace the potentially panicking `[]` indexing with `get_unchecked()` to prevent linking with panic-related code.
Stabilise `const_char_encode_utf16`.
Closes: #130660
This PR stabilises the `const_char_encode_utf16` feature gate (i.e. support for `char::encode_utf16` in constant expressions).
~~Note that the linked tracking issue is as of this writing currently awaiting FCP until 2024-11-02.~~
Improve example of `impl Pattern for &[char]`
The previous version used `['l', 'l']` as pattern, which would suggest that it matches the `ll` of `Hello world` as a whole.
add rustc std workspace crate sources
This adds the sources for the crates listed at https://crates.io/search?q=rustc-std-workspace in this repo. The first commit adds the original sources as downloaded from crates.io (with `Cargo.toml.orig` moved back over `Cargo.toml`), and adds a README explaining what this is about. The 2nd commit updates the sources to make the core and alloc crates re-exports of the "actual" core and alloc crates, as was already the case with `std`, and also adds a `repository` link to the manifest so one can figure out where to find these crates.
I bumped the version for the core and alloc crates in the hope that the new versions can be published on crates.io shortly after this PR lands.
See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/rustc-std-workspace-core.20crate.20is.20empty) for a bit more context.
r? `@Amanieu`
remove const-support for align_offset and is_aligned
As part of the recent discussion to stabilize `ptr.is_null()` in const context, the general vibe was that it's okay for a const function to panic when the same operation would work at runtime (that's just a case of "dynamically detecting that something is not supported as a const operation"), but it is *not* okay for a const function to just return a different result.
Following that, `is_aligned` and `is_aligned_to` have their const status revoked in this PR, since they do return actively wrong results at const time. In the future we can consider having a new intrinsic or so that can check whether a pointer is "guaranteed to be aligned", but the current implementation based on `align_offset` does not have the behavior we want.
In fact `align_offset` itself behaves quite strangely in const, and that support needs a bunch of special hacks. That doesn't seem worth it. Instead, the users that can fall back to a different implementation should just use const_eval_select directly, and everything else should not be made const-callable. So this PR does exactly that, and entirely removes const support for align_offset.
Closes some tracking issues by removing the associated features:
Closes https://github.com/rust-lang/rust/issues/90962
Closes https://github.com/rust-lang/rust/issues/104203
Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
Update `compiler-builtins` and enable f128 tests on all non-buggy platforms
Update compiler_builtins to 0.1.138 and pin it. This updates to a new version of builtins that includes [1], which was
the last blocker to us enabling `f128` tests on all platforms.
With that, we now provide symbols necessary to work with `f128` everywhere. This means that we are no longer restricted to systems that provide `f128` symbols themselves, and can enable tests by default.
There are still a handful of platforms that need to remain disabled because of bugs and some that had to get updated.
Math support is still off by default since those symbols are not yet available.
[1]: https://github.com/rust-lang/compiler-builtins/pull/624
try-job: test-various
try-job: i686-gnu-nopt
With the `compiler-builtins` update to 0.1.137 [1], we now provide
symbols necessary to work with `f128` everywhere. This means that we are
no longer restricted to 64-bit linux, and can enable tests by default.
There are still a handful of platforms that need to remain disabled
because of bugs. This patch additionally disables the following:
1. MIPS [2]
2. 32-bit x86 [3]
Math support is still off by default since those symbols are not yet
available.
[1]: https://github.com/rust-lang/rust/pull/132433
[2]: https://github.com/llvm/llvm-project/issues/96432
[3]: https://github.com/llvm/llvm-project/issues/77401
This updates to a new version of builtins that includes [1], which was
the last blocker to us enabling `f128` tests on all platforms 🎉.
With this update, also change to pinning the version with `=` rather
than using the default carat versioning. This is meant to ensure that
`compiler-builtins` does not get updated as part of the weekly
`Cargo.lock` update, since updates to this crate need to be intentional:
changes to rust-lang/rust and rust-lang/compiler-builtins sometimes need
to be kept in lockstep, unlike most dependencies, and sometimes these
updates can be problematic.
[1]: https://github.com/rust-lang/compiler-builtins/pull/624
Make `std::os::darwin` public
I'm not sure of the reasoning behind them not being public before, but I think they should be, just like `std::os::ios` and `std::os::macos` are public.
Additionally, I've merged their source code, as it was otherwise just a bunch of unnecessary duplication.
Ultimately, I've done this PR to fix `./x build library --target=aarch64-apple-tvos,aarch64-apple-watchos,aarch64-apple-visionos`, as that currently fails because of dead code warnings.
Since you reviewed https://github.com/rust-lang/rust/pull/121419
r? davidtwco
Fixes https://github.com/rust-lang/rust/issues/121640.
`@rustbot` label O-tvos O-watchos O-visionos
Yeet the `effects` feature, move it onto `const_trait_impl`
This PR merges the `effects` feature into the `const_trait_impl` feature. There's really no need to have two feature gates for one feature.
After this PR, if `const_trait_impl` **is** enabled:
* Users can use and define const traits
* `HostEffect` const conditions will be enforced on the HIR
* We re-check the predicates in MIR just to make sure that we don't "leak" anything during MIR lowering
And if `const_trait_impl` **is not** enabled:
* Users cannot use nor define const traits
* `HostEffect` const conditions are not enforced on the HIR
* We will raise a const validation error if we call a function that has any const conditions (i.e. const traits and functions with any `~const` in their where clasues)
This should be the last step for us to be able to enable const traits in the standard library. We still need to re-constify `Drop` and `Destruct` and stuff for const traits to be particularly *useful* for some cases, but this is a good step :D
r? fee1-dead
cc `@rust-lang/project-const-traits`
Operations like is_aligned would return actively wrong results at compile-time,
i.e. calling it on the same pointer at compiletime and runtime could yield
different results. That's no good.
Instead of having hacks to make align_offset kind-of work in const-eval, just
use const_eval_select in the few places where it makes sense, which also ensures
those places are all aware they need to make sure the fallback behavior is
consistent.
This change updates the documentation for `NonZero` integer types to
explicitly reference the underlying integer type each `NonZero` variant
wraps, instead of using a general "integer" term.
better test for const HashMap; remove const_hash leftovers
The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (https://github.com/rust-lang/rust/issues/123197), so we also have a test that does not involve that type.
The second commit removes the last remnants of https://github.com/rust-lang/rust/issues/104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`.
Cc ``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval``
Closes#104061
Related to https://github.com/rust-lang/rust/issues/102575
Add LowerExp and UpperExp implementations to NonZero
Adds `LowerExp` and `UpperExp` trait implementations to `NonZero`, as discussed in rust-lang/libs-team#458.
I had to modify the macro to mark the new impls with a different rust version. Let me know if this is the right way to do it (first timer here!)
Implement `From<&mut {slice}>` for `Box/Rc/Arc<{slice}>`
ACP: https://github.com/rust-lang/libs-team/issues/424
New API:
```rust
impl<T: Clone> From<&mut [T]> for Box<[T]>
impl From<&mut str> for Box<str>
impl From<&mut CStr> for Box<CStr>
impl From<&mut OsStr> for Box<OsStr>
impl From<&mut Path> for Box<Path>
impl<T: Clone> From<&mut [T]> for Rc<[T]>
impl From<&mut str> for Rc<str>
impl From<&mut CStr> for Rc<CStr>
impl From<&mut OsStr> for Rc<OsStr>
impl From<&mut Path> for Rc<Path>
impl<T: Clone> From<&mut [T]> for Arc<[T]>
impl From<&mut str> for Arc<str>
impl From<&mut CStr> for Arc<CStr>
impl From<&mut OsStr> for Arc<OsStr>
impl From<&mut Path> for Arc<Path>
```
Since they are trait implementations, I think these are insta-stable.
As mentioned in https://github.com/rust-lang/libs-team/issues/424#issuecomment-2299415749, a crater run might be needed.
get rid of a whole bunch of unnecessary rustc_const_unstable attributes
In general, when a `const fn` is still unstable, it doesn't need a `#[rustc_const_unstable]` attribute. The only exception is functions that internally use things that can't be used in stable const fn yet.
So this gets rid of a whole bunch of `#[rustc_const_unstable]` in libcore.
Remove unintended link
Since `#[link_section]` is enclosed in braces, it was being confused with a link during docs compilation.
This caused compilation to fail when running `x dist` since it emitted a warning regarding broken links.
Fix type reference in documents which was being confused with html tags.
Running `x dist` was failing due to it invoking commands with `-D warnings`, which emitted a warning about unclosed html tags.
library: fix some stability annotations
This PR updates some stability attributes to correctly reflect when some items actually got stabilized. Found while testing https://github.com/rust-lang/rust/pull/132481.
### `core::char` / `std::char`
In https://github.com/rust-lang/rust/pull/26192, the `core::char` module got "stabilized" for 1.2.0, but the `core` crate itself was still unstable until 1.6.0.
In https://github.com/rust-lang/rust/pull/49698, the `std::char` module was changed to a re-export of `core::char`, making `std::char` appear as "stable since 1.2.0", even though it was already stable in 1.0.0.
By marking `core::char` as stable since 1.0.0, the docs will show correct versions for both `core::char` (since 1.6.0) and `std::char` (since 1.0.0). This is also consistent with the stabilities of similar re-exported modules like `core::mem`/`std::mem` for example.
### `{core,std}::array` and `{core,std}::array::TryFromSliceError`
In https://github.com/rust-lang/rust/pull/58302, the `core::array::TryFromSliceError` type got stabilized for 1.34.0, together with `TryFrom`. At that point the `core::array` module was still unstable and a `std::array` re-export didn't exist, but `core::array::TryFromSliceError` could still be named due to https://github.com/rust-lang/rust/pull/95956 to existing yet.
Then, `core::array` got stabilized and `std::array` got added, first targeting 1.36.0 in https://github.com/rust-lang/rust/pull/60657, but then getting backported for 1.35.0 in https://github.com/rust-lang/rust/pull/60838.
This means that `core::array` and `std::array` actually got stabilized in 1.35.0 and `core::array::TryFromSliceError` was accessible through the unstable module in 1.34.0 -- mark them as such so that the docs display the correct versions.
feat(byte_sub_ptr): unstably add ptr::byte_sub_ptr
This is an API that naturally should exist as a combination of byte_offset_from and sub_ptr
both existing (they showed up at similar times so this union was never made). Adding these
is a logical (and perhaps final) precondition of stabilizing ptr_sub_ptr (https://github.com/rust-lang/rust/issues/95892).
Original PR by ``@Gankra`` (https://github.com/rust-lang/rust/pull/121919), I am just reviving it. The 2nd commit (with a small docs tweak) is by me.
