Update grammar in std::cell docs.
Using "having" in both the leading sentence and the bullets is unnecessary.
It makes it read as "it is only possible to have having several immutable...".
split up the first paragraph of doc comments for better summaries
used `./x clippy -Aclippy::all '-Wclippy::too_long_first_doc_paragraph' library/core library/alloc` to find these issues.
Arbitrary self types v2: (unused) Receiver trait
This commit contains a new `Receiver` trait, which is the basis for the Arbitrary Self Types v2 RFC. This allows smart pointers to be method receivers even if they're not Deref.
This is currently unused by the compiler - a subsequent PR will start to use this for method resolution if the `arbitrary_self_types` feature gate is enabled. This is being landed first simply to make review simpler: if people feel this should all be in an atomic PR let me know.
This is a part of the arbitrary self types v2 project, https://github.com/rust-lang/rfcs/pull/3519https://github.com/rust-lang/rust/issues/44874
r? `@wesleywiser`
Using "having" in both the leading sentence and the bullets is unnecessary.
It makes it read as "it is only possible to have having several immutable...".
Implement file_lock feature
This adds lock(), lock_shared(), try_lock(), try_lock_shared(), and unlock() to File gated behind the file_lock feature flag
This is the initial implementation of https://github.com/rust-lang/rust/issues/130994 for Unix and Windows platforms. I will follow it up with an implementation for WASI preview 2
ABI compatibility: remove section on target features
Once https://github.com/rust-lang/rust/pull/127731 lands, we will properly diagnose ABI issues caused by target feature mismatch (at least on tier 1 targets). So I'd say we can remove the corresponding part of the docs here -- this is now something the compiler can take care of, so programmers don't need to be concerned. For now this is just a lint, but that's just a transition period, like in prior cases where we fix I-unsound bugs by adding a new check that goes through the "future incompatibility" stages. We have decided that it's actually a bug that we have ABI risks around target features, and we shouldn't document that bug as-if it was intended behavior.
Cc `@rust-lang/opsem` `@chorman0773` `@veluca93`
remove support for rustc_safe_intrinsic attribute; use rustc_intrinsic functions instead
This brings us one step closer towards removing support for `extern "rust-intrinsic"` blocks, in favor of `#[rustc_intrinsic]` functions.
Also move `#[rustc_intrinsic]` under the `intrinsics` feature gate, to match the `extern "rust-intrinsic"` style.
Initialize channel `Block`s directly on the heap
The channel's `Block::new` was causing a stack overflow because it held
32 item slots, instantiated on the stack before moving to `Box::new`.
The 32x multiplier made modestly-large item sizes untenable.
That block is now initialized directly on the heap.
Fixes#102246
try-job: test-various
Compile `test_num_f128` conditionally on `reliable_f128_math` config
With #132434 merged, our internal SGX CI started failing with:
```
05:27:34 = note: rust-lld: error: undefined symbol: fmodl
05:27:34 >>> referenced by arith.rs:617 (core/src/ops/arith.rs:617)
05:27:34 >>> /home/jenkins/workspace/rust-sgx-ci/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-fortanix-unknown-sgx/release/deps/std-5d5f11eb008c9091.std.d8141acc61ab7ac8-cgu.10.rcgu.o:(std::num::test_num::h7dd9449f6c01fde8)
05:27:34 >>> did you mean: fmodf
05:27:34 >>> defined in: /home/jenkins/workspace/rust-sgx-ci/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-fortanix-unknown-sgx/release/deps/libcompiler_builtins-0376f439a2ebf305.rlib(compiler_builtins-0376f439a2ebf305.compiler_builtins.c22db39d25d6f802-cgu.148.rcgu.o)
```
This originated from the `test_num_f128` test not having the required conditional compilation. This PR fixes that issue.
cc: ````@jethrogb,```` ````@workingjubilee````
core: move intrinsics.rs into intrinsics folder
This makes the rustbot notification we have set up for this folder in `triagebot.toml` actually work. Also IMO it makes more sense to have it all in one folder.
The channel's `Block::new` was causing a stack overflow because it held
32 item slots, instantiated on the stack before moving to `Box::new`.
The 32x multiplier made modestly-large item sizes untenable.
That block is now initialized directly on the heap.
Fixes#102246
unpin and update memchr
I'm unable to build x86_64-pc-windows-gnu Rust due to some weird binutils bug, but thinlto issue seems to be no longer present. Let's give it a go on the CI.
Possibly fixed by https://github.com/rust-lang/rust/pull/129079Fixes#127890
Inline str::repeat
`str` is non-generic and `str.repeat()` doesn't get inlined, which makes it use a slower algorithm in case of 1-char repetitions. Equivalent byte slice does get inlined: https://rust.godbolt.org/z/4arvh97r4
Revert using `HEAP` static in Windows alloc
Fixes#131468
This does the minimum to remove the `HEAP` static that was causing chromium issues. It would be worth having a more substantial look at this module but for now I think this addresses the immediate issue.
cc `@danakj`
Fix an extra newline in rendered std doc
Fixes#132564
(taken from the issue above)
The problem with the formatting is due to that newline between `<code>` and `<svg>`. Any newlines outside of the code (i.e., within elements inside of it) are fine.
Add new unstable feature `const_eq_ignore_ascii_case`
Tracking issue - #131719
Mark `[u8]`, `str` `eq_ignore_ascii_case` functions const
---
The codegen for this implementation matches the existing `iter::zip` implementation better than incrementing with a counter
while loop with counter - https://rust.godbolt.org/z/h9cs5zajc
while let - https://rust.godbolt.org/z/ecMeMjjEb
make char::is_whitespace unstably const
I am adding this to the existing https://github.com/rust-lang/rust/issues/132241 feature gate, since `is_digit` and `is_whitespace` seem similar enough that one can group them together.
Rollup of 8 pull requests
Successful merges:
- #132259 (rustc_codegen_llvm: Add a new 'pc' option to branch-protection)
- #132409 (CI: switch 7 linux jobs to free runners)
- #132498 (Suggest fixing typos and let bindings at the same time)
- #132524 (chore(style): sync submodule exclusion list between tidy and rustfmt)
- #132567 (Properly suggest `E::assoc` when we encounter `E::Variant::assoc`)
- #132571 (add const_eval_select macro to reduce redundancy)
- #132637 (Do not filter empty lint passes & re-do CTFE pass)
- #132642 (Add documentation on `ast::Attribute`)
r? `@ghost`
`@rustbot` modify labels: rollup
add const_eval_select macro to reduce redundancy
I played around a bit with a macro to make const_eval_select invocations look a bit nicer and avoid repeating the argument lists. Here's what I got. What do you think?
I didn't apply this everywhere yet because I wanted to gather feedback first.
The second commit moves the macros from https://github.com/rust-lang/rust/pull/132542 into a more sensible place. It didn't seem worth its own PR and would conflict with this PR if done separately.
Cc ``@oli-obk`` ``@saethlin`` ``@tgross35``
try-job: dist-aarch64-msvc
[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.
