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)
