Clarify language around ptrs in slice::raw
More specifically we explicitly mention that the pointer should be non-null as a top level requirement. Nullptrs are always valid for zero sized operations, so just validity (and alignment) does not guarantee non-nullness as implied in the existing docs.
We also explicitly call out ZSTs as an additional example where perhaps unintuitively alignment and non-nullness still have to hold.
Finally we change `data` in the range functions to `start`, which seems like a typo to me.
Touches docs for #89792
r? RalfJung
compiler_fence documentation: emphasize synchronization, not reordering
Our `fence` docs have at some point been update to explain that they are about synchronization, not about "preventing reordering". This updates the `compiler_fence` docs n the same vein, mostly by referring to the `fence` docs.
The old docs make it sound like I can put a compiler_fence in the middle of a bunch of non-atomic operations and that would achieve any kind of guarantee. It does not, atomic operations are still required to do synchronization.
I also slightly tweaked the `fence` docs, to put the synchronization first and the "prevent reordering" second.
Cc `@rust-lang/opsem` `@chorman0773` `@m-ou-se`
Fixes https://github.com/rust-lang/rust/issues/129189
Fixes https://github.com/rust-lang/rust/issues/54962
Rollup of 9 pull requests
Successful merges:
- #127474 (doc: Make block of inline Deref methods foldable)
- #129678 (Deny imports of `rustc_type_ir::inherent` outside of type ir + new trait solver)
- #129738 (`rustc_mir_transform` cleanups)
- #129793 (add extra linebreaks so rustdoc can identify the first sentence)
- #129804 (Fixed some typos in the standard library documentation/comments)
- #129837 (Actually parse stdout json, instead of using hacky contains logic.)
- #129842 (Fix LLVM ABI NAME for riscv64imac-unknown-nuttx-elf)
- #129843 (Mark myself as on vacation for triagebot)
- #129858 (Replace walk with visit so we dont skip outermost expr kind in def collector)
Failed merges:
- #129777 (Add `unreachable_pub`, round 4)
- #129868 (Remove kobzol vacation status)
r? `@ghost`
`@rustbot` modify labels: rollup
add extra linebreaks so rustdoc can identify the first sentence
there should probably be a lint against this in rustdoc, it causes too many lines to be shown in the short documentation overviews
expecially noticable for the slice primative type: https://doc.rust-lang.org/std/index.html
Apply size optimizations to panic machinery and some cold functions
* std dependencies gimli and addr2line are now built with opt-level=s
* various panic-related methods and `#[cold]` methods are now marked `#[optimize(size)]`
Panics should be cold enough that it doesn't make sense to optimize them for speed. The only tradeoff here is if someone does a lot of backtrace captures (without panics) and printing then the opt-level change might impact their perf.
Seems to be the first use of the optimize attribute. Tracking issue #54882
there should probably be a lint against this in rustdoc, it causes
too many lines to be shown in the short documentation overviews
expecially noticable for the slice primative type:
https://doc.rust-lang.org/std/index.html
refactor: standardize duplicate processes in parser
## Summary
This PR refactors the `read_number` function to standardize duplicate code, improve readability, and enhance efficiency.
## Changes
- Merged the logic for both `max_digits` cases into a single `read_atomically` closure
- Simplified control flow and reduced code duplication
core: use `compare_bytes` for more slice element types
`bool`, `NonZero<u8>`, `Option<NonZero<u8>>` and `ascii::Char` can be compared the same way as `u8`.
Rollup of 11 pull requests
Successful merges:
- #128523 (Add release notes for 1.81.0)
- #129605 (Add missing `needs-llvm-components` directives for run-make tests that need target-specific codegen)
- #129650 (Clean up `library/profiler_builtins/build.rs`)
- #129651 (skip stage 0 target check if `BOOTSTRAP_SKIP_TARGET_SANITY` is set)
- #129684 (Enable Miri to pass pointers through FFI)
- #129762 (Update the `wasm-component-ld` binary dependency)
- #129782 (couple more crash tests)
- #129816 (tidy: say which feature gate has a stability issue mismatch)
- #129818 (make the const-unstable-in-stable error more clear)
- #129824 (Fix code examples buttons not appearing on click on mobile)
- #129826 (library: Fix typo in `core::mem`)
r? `@ghost`
`@rustbot` modify labels: rollup
Two improvements to the documentation:
- Document `-` as a valid character for signed integer destinations
- Make the documentation even more clear that extra whitespace and non-digit characters is invalid. Many other
languages, e.g. c++, are very permissive in string to integer routines and simply try to consume as much as they can,
ignoring the rest. This is trying to make the transition for developers who are used to the conversion semantics in
these languages a bit easier.
Re-enable android tests/benches in alloc/core
This is basically a revert of https://github.com/rust-lang/rust/pull/73729. These tests better work on android now; it's been 4 years and we don't use dlmalloc on that target anymore.
And I've validated that they should pass now with a try-build :)
* Use a lookup table for 8-bit integers and the Karatsuba square root
algorithm for larger integers.
* Include optimization hints that give the compiler the exact numeric
range of results.
* Choose test inputs more thoroughly and systematically.
* Check that `isqrt` and `checked_isqrt` have equivalent results for
signed types, either equivalent numerically or equivalent as a panic
and a `None`.
* Check that `isqrt` has numerically-equivalent results for unsigned
types and their `NonZero` counterparts.
* Reuse `ilog10` benchmarks, plus benchmarks that use a uniform
distribution.
Rollup of 11 pull requests
Successful merges:
- #129421 (add repr to the allowlist for naked functions)
- #129480 (docs: correct panic conditions for rem_euclid and similar functions)
- #129551 (ub_checks intrinsics: fall back to cfg(ub_checks))
- #129608 (const-eval: do not make UbChecks behavior depend on current crate's flags)
- #129613 (interpret: do not make const-eval query result depend on tcx.sess)
- #129641 (rustdoc: fix missing resource suffix on `crates.js`)
- #129657 (Rename `BikeshedIntrinsicFrom` to `TransmuteFrom`)
- #129666 (interpret: add missing alignment check in raw_eq)
- #129667 (Rustc driver cleanup)
- #129668 (Fix Pin::set bounds regression)
- #129686 (coverage: Rename `CodeRegion` to `SourceRegion`)
r? `@ghost`
`@rustbot` modify labels: rollup
Rename `BikeshedIntrinsicFrom` to `TransmuteFrom`
As our implementation of MCP411 nears completion and we begin to solicit testing, it's no longer reasonable to expect testers to type or remember `BikeshedIntrinsicFrom`. The name degrades the ease-of-reading of documentation, and the overall experience of using compiler safe transmute.
Tentatively, we'll instead adopt `TransmuteFrom`.
This name seems to be the one most likely to be stabilized, after discussion on Zulip [1]. We may want to revisit the ordering of `Src` and `Dst` before stabilization, at which point we'd likely consider `TransmuteInto` or `Transmute`.
[1] https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/What.20should.20.60BikeshedIntrinsicFrom.60.20be.20named.3F
Tracking Issue: https://github.com/rust-lang/rust/issues/99571
r? `@compiler-errors`
ub_checks intrinsics: fall back to cfg(ub_checks)
Not sure why the fallback body uses `debug_assertions`, probably a leftover from when `cfg!(ub_checks)` did not exist yet?
r? `@saethlin`
Tweak some attributes to improve panic_immediate_abort
This is similar to https://github.com/rust-lang/rust/pull/117332; I did the same approach as before where I build a really big project with `-Zbuild-std -Zbuild-std-features=panic_immediate_abort` and grep its symbols for things that look panic-related.
Fix typos in floating-point primitive type docs
Fixes a few typos. Also reflows the text of a couple of paragraphs in the source code to the standard line width to make the source easier to read (will have no effect on the rendered documentation).
As our implementation of MCP411 nears completion and we begin to
solicit testing, it's no longer reasonable to expect testers to
type or remember `BikeshedIntrinsicFrom`. The name degrades the
ease-of-reading of documentation, and the overall experience of
using compiler safe transmute.
Tentatively, we'll instead adopt `TransmuteFrom`.
This name seems to be the one most likely to be stabilized, after
discussion on Zulip [1]. We may want to revisit the ordering of
`Src` and `Dst` before stabilization, at which point we'd likely
consider `TransmuteInto` or `Transmute`.
[1] https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/What.20should.20.60BikeshedIntrinsicFrom.60.20be.20named.3F
simd_shuffle intrinsic: allow argument to be passed as vector
See https://github.com/rust-lang/rust/issues/128738 for context.
I'd like to get rid of [this hack](6c0b89dfac/compiler/rustc_codegen_ssa/src/mir/block.rs (L922-L935)). https://github.com/rust-lang/rust/pull/128537 almost lets us do that since constant SIMD vectors will then be passed as immediate arguments. However, simd_shuffle for some reason actually takes an *array* as argument, not a vector, so the hack is still required to ensure that the array becomes an immediate (which then later stages of codegen convert into a vector, as that's what LLVM needs).
This PR prepares simd_shuffle to also support a vector as the `idx` argument. Once this lands, stdarch can hopefully be updated to pass `idx` as a vector, and then support for arrays can be removed, which finally lets us get rid of that hack.
Document & implement the transmutation modeled by `BikeshedIntrinsicFrom`
Documents that `BikeshedIntrinsicFrom` models transmute-via-union, which is slightly more expressive than the transmute-via-cast implemented by `transmute_copy`. Additionally, we provide an implementation of transmute-via-union as a method on the `BikeshedIntrinsicFrom` trait with additional documentation on the boundary between trait invariants and caller obligations.
Whether or not transmute-via-union is the right kind of transmute to model remains up for discussion [1]. Regardless, it seems wise to document the present behavior.
[1] https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/What.20'kind'.20of.20transmute.20to.20model.3F/near/426331967
Tracking Issue: https://github.com/rust-lang/rust/issues/99571
r? `@compiler-errors`
cc `@scottmcm,` `@Lokathor`
Remove cfg(test) from library/core
The diff here is very small with the ignore whitespace option.
`core` doesn't/can't have unit tests. All of its tests are just modules under `tests/`, so it has no use for `cfg(test)`, because the entire contents of `library/core/src` are only ever compiled with that cfg off, and the entire contents of `library/core/tests` are only ever compiled with that cfg on.
You can tell this is what's happening because we had `#[cfg(test)]` on a module declaration that has no source file.
I also deleted the extra `mod tests {` layer of nesting; there's no need to mention again in the module path that this is a module of tests. This exposes a name collision between the `u128` module of tests and `core::u128`. Fixed that by using `<u128>::MAX` like is done in the `check!` macro, which is what avoids this name ambiguity for the other types.
link to Future::poll from the Poll docs
The most important thing about Poll is that Future::poll returns it, but previously the docs didn't emphasize this.
Add implementations for `unbounded_shl`/`unbounded_shr`
Tracking Issue: https://github.com/rust-lang/rust/issues/129375
This implements `unbounded_shl` and `unbounded_shr` under the feature gate `unbounded_shifts`
Rollup of 9 pull requests
Successful merges:
- #129288 (Use subtyping for `UnsafeFnPointer` coercion, too)
- #129405 (Fixing span manipulation and indentation of the suggestion introduced by #126187)
- #129518 (gitignore: ignore ICE reports regardless of directory)
- #129519 (Remove redundant flags from `lower_ty_common` that can be inferred from the HIR)
- #129525 (rustdoc: clean up tuple <-> primitive conversion docs)
- #129526 (Use `FxHasher` on new solver unconditionally)
- #129544 (Removes dead code from the compiler)
- #129553 (add back test for stable-const-can-only-call-stable-const)
- #129590 (Avoid taking reference of &TyKind)
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: clean up tuple <-> primitive conversion docs
This adds a minor missing feature to `fake_variadic`, so that it can render `impl From<(T,)> for [T; 1]` correctly.
Put Pin::as_deref_mut in impl Pin<Ptr> / rearrange Pin methods
Tracking issue: #86918
Based on the suggestion in https://github.com/rust-lang/rust/issues/86918#issuecomment-2189367582
> Some advantages:
>
> * Synergy with the existing `as_ref` and `as_mut` signatures (stable since Rust 1.33)
>
> * Lifetime elision reduces noise in the signature
>
> * Turbofish less verbose: `Pin::<&mut T>::as_deref_mut` vs `Pin::<&mut Pin<&mut T>>::as_deref_mut`
The comment seemed to imply that `Pin::as_ref` and `Pin::as_mut` already share an impl block, which they don't. So, I rearranged it so that they do, and we can see which looks better in the docs.
<details><summary><b>Docs screenshots</b></summary>
Current nightly:
`Pin::as_deref_mut` moved into the same block as `as_mut`:
`Pin::as_ref`, `as_mut`, and `as_deref_mut` all in the same block:
</details>
I think I like the last one the most; obviously I'm biased since I'm the one who rearranged it, but it doesn't make sense to me to have `as_ref` methods split up by an `into_inner` method.
r? dtolnay
Add a special case for `CStr`/`CString` in the `improper_ctypes` lint
Revives #120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise.
Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.
The suggestion is not made for `&mut CString` or `*mut CString`.
r? ``````@cjgillot`````` (since you were the reviewer of the original PR #120176, but feel free to reroll)
remove invalid `TyCompat` relation for effects
if the current impl uses `Maybe` (`impl const`), the parent impl must use `Maybe` (`impl const`) as well.
I'd like to rename `TyCompat` to `Sub` which is probably clearer. But it would conflict with my other PR.
r? ``@rust-lang/project-const-traits``
Documents that `BikeshedIntrinsicFrom` models transmute-via-union,
which is slightly more expressive than the transmute-via-cast
implemented by `transmute_copy`. Additionally, we provide an
implementation of transmute-via-union as a method on the
`BikeshedIntrinsicFrom` trait with additional documentation on
the boundary between trait invariants and caller obligations.
Whether or not transmute-via-union is the right kind of transmute
to model remains up for discussion [1]. Regardless, it seems wise
to document the present behavior.
[1] https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/What.20'kind'.20of.20transmute.20to.20model.3F/near/426331967
Stabilize feature `char_indices_offset`
Stabilized API:
```rust
impl CharIndices<'_> {
pub fn offset(&self) -> usize;
}
```
Tracking issue: https://github.com/rust-lang/rust/issues/83871
Closes https://github.com/rust-lang/rust/issues/83871
I also attempted to improved the documentation to make it more clear that it returns the offset of the character that will be returned by the next call to `next()`.
Rollup of 8 pull requests
Successful merges:
- #128432 (WASI: forbid `unsafe_op_in_unsafe_fn` for `std::{os, sys}`)
- #129373 (Add missing module flags for CFI and KCFI sanitizers)
- #129374 (Use `assert_unsafe_precondition!` in `AsciiChar::digit_unchecked`)
- #129376 (Change `assert_unsafe_precondition` docs to refer to `check_language_ub`)
- #129382 (Add `const_cell_into_inner` to `OnceCell`)
- #129387 (Advise against removing the remaining Python scripts from `tests/run-make`)
- #129388 (Do not rely on names to find lifetimes.)
- #129395 (Pretty-print own args of existential projections (dyn-Trait w/ GAT constraints))
r? `@ghost`
`@rustbot` modify labels: rollup
Add `const_cell_into_inner` to `OnceCell`
`Cell` and `RefCell` have their `into_inner` methods const unstable. `OnceCell` has the same logic, so add it under the same gate.
Tracking issue: https://github.com/rust-lang/rust/issues/78729
`Cell` and `RefCell` have their `into_inner` methods const unstable.
`OnceCell` has the same logic, so add it under the same gate.
Tracking issue: https://github.com/rust-lang/rust/issues/78729
Implement `debug_more_non_exhaustive`
This implements the ACP at https://github.com/rust-lang/libs-team/issues/248, adding `.finish_non_exhaustive()` for `DebugTuple`, `DebugSet`, `DebugList`, and `DebugMap`.
Also used this as an opportunity to make some documentation and tests more readable by using raw strings instead of escaped quotes.
Tracking issue: https://github.com/rust-lang/rust/issues/127942
Add a precondition check for Layout::from_size_align_unchecked
Ran into this while looking into https://github.com/rust-lang/miri/issues/3679. This is of course not the cause of the ICE, but the reproducer doesn't encounter a precondition check and it ought to.
CloneToUninit impls
As per #126799.
Also implements it for `Wtf8` and both versions of `os_str::Slice`.
Maybe it is worth to slap `#[inline]` on some of those impls.
r? `@dtolnay`
float to/from bits and classify: update for float semantics RFC
With https://github.com/rust-lang/rfcs/pull/3514 having been accepted, it is clear that hardware which e.g. flushes subnormal to zero is just non-conformant from a Rust perspective -- this is a hardware bug, or maybe an LLVM backend bug (where LLVM doesn't lower floating-point ops in a way that they have the standardized behavior). So update the comments here to make it clear that we don't have to do any of this, we're just being nice.
Also remove the subnormal/NaN checks from the (unstable) const-version of to/from-bits; they are not needed since we decided with the aforementioned RFC that it is okay to get a different result at const-time and at run-time.
r? `@workingjubilee` since I think you wrote many of the comments I am editing here.
Implement DoubleEnded and ExactSize for Take<Repeat> and Take<RepeatWith>
Repeat iterator always returns the same element and behaves the same way
backwards and forwards. Take iterator can trivially implement backwards
iteration over Repeat inner iterator by simply doing forwards iteration.
DoubleEndedIterator is not currently implemented for Take<Repeat<T>>
because Repeat doesn’t implement ExactSizeIterator which is a required
bound on DEI implementation for Take.
Similarly, since Repeat is an infinite iterator which never stops, Take
can trivially know how many elements it’s going to return. This allows
implementing ExactSizeIterator on Take<Repeat<T>>.
While at it, observe that ExactSizeIterator can also be implemented for
Take<RepeatWhile<F>> so add that implementation too. Since in contrast
to Repeat, RepeatWhile doesn’t guarante to always return the same value,
DoubleEndedIterator isn’t implemented.
Those changes render core::iter::repeat_n somewhat redundant.
Issue: https://github.com/rust-lang/rust/issues/104434
Issue: https://github.com/rust-lang/rust/issues/104729
- [ ] ACP: https://github.com/rust-lang/libs-team/issues/120 (this is actually ACP for repeat_n but this is nearly the same functionality so hijacking it so both approaches can be discussed in one place)
Improve docs for Waker::noop and LocalWaker::noop
* Add a warning about a likely misuse. (See my commit message for longer rationale.)
* Apply some probably-accidentally-omitted changes to `LocalWaker`'s docs
* Add a comment about the clone-and-hack of the docs
I have used [semantic linefeeds](https://rhodesmill.org/brandon/2012/one-sentence-per-line/) for the docs formatting.
Hash Ipv*Addr as an integer
The `Ipv4Addr` and `Ipv6Addr` structs always have a fixed size, but directly derive `Hash`. This causes them to call the bytestring hasher implementation, which adds extra work for most hashers. This PR converts the internal representation to a fixed-width integer before passing to the hasher to prevent this.
derive(SmartPointer): register helper attributes
Fix#128888
This PR enables built-in macros to register helper attributes, if any, to support correct name resolution in the correct lexical scope under the macros.
Also, `#[pointee]` is moved into the scope under `derive(SmartPointer)`.
cc `@Darksonn` `@davidtwco`
Explicitly specify type parameter on FromResidual for Option and ControlFlow.
~~Remove type parameter default `R = <Self as Try>::Residual` from `FromResidual`~~ _Specify default type parameter on `FromResidual` impls in the stdlib_ to work around https://github.com/rust-lang/rust/issues/99940 / https://github.com/rust-lang/rust/issues/87350 ~~as mentioned in https://github.com/rust-lang/rust/issues/84277#issuecomment-1773259264~~.
This does not completely fix the issue, but works around it for `Option` and `ControlFlow` specifically (`Result` does not have the issue since it already did not use the default parameter of `FromResidual`).
~~(Does this need an ACP or similar?)~~ ~~This probably needs at least an FCP since it changes the API described in [the RFC](https://github.com/rust-lang/rfcs/pull/3058). Not sure if T-lang, T-libs-api, T-libs, or some combination (The tracking issue is tagged T-lang, T-libs-api).~~ This probably doesn't need T-lang input, since it is not changing the API of `FromResidual` from the RFC? Maybe needs T-libs-api FCP?
Rollup of 7 pull requests
Successful merges:
- #122884 (Optimize integer `pow` by removing the exit branch)
- #127857 (Allow to customize `// TODO:` comment for deprecated safe autofix)
- #129034 (Add `#[must_use]` attribute to `Coroutine` trait)
- #129049 (compiletest: Don't panic on unknown JSON-like output lines)
- #129050 (Emit a warning instead of an error if `--generate-link-to-definition` is used with other output formats than HTML)
- #129056 (Fix one usage of target triple in bootstrap)
- #129058 (Add mw back to review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Add `#[must_use]` attribute to `Coroutine` trait
[Coroutines tracking issue](https://github.com/rust-lang/rust/issues/43122)
Like closures (`FnOnce`, `AsyncFn`, etc.), coroutines are lazy and do nothing unless called (resumed). Closure traits like `FnOnce` have `#[must_use = "closures are lazy and do nothing unless called"]` to catch likely bugs for users of APIs that produce them. This PR adds such a `#[must_use]` attribute to `trait Coroutine`.
Optimize integer `pow` by removing the exit branch
The branch at the end of the `pow` implementations is redundant with multiplication code already present in the loop. By rotating the exit check, this branch can be largely removed, improving code size and reducing instruction cache misses.
Testing on my machine (`x86_64`, 11th Gen Intel Core i5-1135G7 @ 2.40GHz), the `num::int_pow` benchmarks improve by some 40% for the unchecked operations and show some slight improvement for the checked operations as well.
miri: make vtable addresses not globally unique
Miri currently gives vtables a unique global address. That's not actually matching reality though. So this PR enables Miri to generate different addresses for the same type-trait pair.
To avoid generating an unbounded number of `AllocId` (and consuming unbounded amounts of memory), we use the "salt" technique that we also already use for giving constants non-unique addresses: the cache is keyed on a "salt" value n top of the actually relevant key, and Miri picks a random salt (currently in the range `0..16`) each time it needs to choose an `AllocId` for one of these globals -- that means we'll get up to 16 different addresses for each vtable. The salt scheme is integrated into the global allocation deduplication logic in `tcx`, and also used for functions and string literals. (So this also fixes the problem that casting the same function to a fn ptr over and over will consume unbounded memory.)
r? `@saethlin`
Fixes https://github.com/rust-lang/miri/issues/3737
nontemporal_store: make sure that the intrinsic is truly just a hint
The `!nontemporal` flag for stores in LLVM *sounds* like it is just a hint, but actually, it is not -- at least on x86, non-temporal stores need very special treatment by the programmer or else the Rust memory model breaks down. LLVM still treats these stores as-if they were normal stores for optimizations, which is [highly dubious](https://github.com/llvm/llvm-project/issues/64521). Let's avoid all that dubiousness by making our own non-temporal stores be truly just a hint, which is possible on some targets (e.g. ARM). On all other targets, non-temporal stores become regular stores.
~~Blocked on https://github.com/rust-lang/stdarch/pull/1541 propagating to the rustc repo, to make sure the `_mm_stream` intrinsics are unaffected by this change.~~
Fixes https://github.com/rust-lang/rust/issues/114582
Cc `@Amanieu` `@workingjubilee`
fix: #128855 Ensure `Guard`'s `drop` method is removed at `opt-level=s` for `…
fix: #128855
…Copy` types
Added `#[inline]` to the `drop` method in the `Guard` implementation to ensure that the method is removed by the compiler at optimization level `opt-level=s` for `Copy` types. This change aims to align the method's behavior with optimization expectations and ensure it does not affect performance.
r? `@scottmcm`
