Also, delete impls on non-Deref types.
Pin doesn't do anything useful for non-Deref types, so PinCoerceUnsized
on such types makes no sense.
This is a breaking change, since stable code can observe the deleted
`PinCoerceUnsized` impls by uselessly coercing between such types
inside a `Pin`.
There is still some strange behavior, such as `Pin<&mut i32>` being
able to coerce to `Pin<&dyn Send>`, but not being able to coerce to
`Pin<&i32>`. However, I don't think it's possible to fix this.
Fixes https://github.com/rust-lang/rust/issues/145081
refactor 'valid for read/write' definition: exclude null
This is an attempt to resolve https://github.com/rust-lang/rust/issues/138351.
The underlying problem is that when we decided to allow reads/writes/copies of size 0 even for null pointers, we documented that by changing the definition of "valid for read/write" in the standard library to say that null pointers are valid for 0-sized reads/writes. Unfortunately, that definition is also used in other places that assume that a valid-for-read/write pointer can be converted into a reference, and of course that's UB if the pointer is null, even if the pointee is a ZST.
The proposal for fixing this is to make "valid for reads/writes" slightly [weaker](https://faultlore.com/blah/tower-of-weakenings/) than it has to be, and require the pointer to be non-null, and then to add exceptions to the most basic functions (read/write/copy) to explicitly allow arbitrary pointers when the size is 0. This isn't pretty but it's the best solution that has been suggested so far I think.
Cc @rust-lang/opsem @rust-lang/libs-api
GVN: Elide more intermediate transmutes
We already skipped intermediate steps like `u32` or `i32` that support any (initialized) value.
This extends that to also allow skipping intermediate steps whose values are a superset of either the source or destination type. Most importantly, that means that `usize` → `NonZeroUsize` → `ptr::Alignment` and `ptr::Alignment` → `NonZeroUsize` → `usize` can skip the middle because `NonZeroUsize` is a superset of `Alignment`.
Then `Alignment::as_usize` is updated to take advantage of that and let us remove some more locals in a few places.
r? cjgillot
Removes the attribute from `MetaSized` and `PointeeSized`, with a special case in the trait solvers for `MetaSized`.
`dyn MetaSized` is a perfectly cromulent type, and seems to only have had #[rustc_do_not_implement_via_object] so the builtin object
candidate does not overlap with the builtin MetaSized impl that all `dyn` types get.
Resolves this with a special case by checking `is_sizedness_trait` where the trait solvers previously checked `implement_via_object`.
`dyn PointeeSized` alone is rejected for other reasons (since `dyn PointeeSized` is considered to have no principal trait because `PointeeSized`
is removed at an earlier stage of the compiler), but `(dyn PointeeSized + Send)` is valid and equivalent to `dyn Send`.
Add suggestions from code review
Update compiler/rustc_trait_selection/src/traits/dyn_compatibility.rs and tests
Co-authored-by: lcnr <rust@lcnr.de>
Removes the double subject "it" in the safety documentation of
`core::ptr::split_at_mut` for raw slice pointers, as it does not refer
to anything.
Reported-by: Johnathan Van Why <jrvanwhy@betterbytes.org>
Adds diagnostic items for `core::ptr::without_provenance` and `core::ptr::without_provenance_mut`. Will be used to enhance clippy lint `transmuting_null`, see https://github.com/rust-lang/rust-clippy/pull/16336.
These `TrivialClone` impls previously had `?Sized` bounds, which are
different from the `PointeeSized` bounds on the corresponding
`Clone` and `Copy` impls. So, I've changed the `?Sized` bounds into
`PointeeSized` bounds.
This mistake was made presumably because the `TrivialClone` PR
(https://github.com/rust-lang/rust/pull/135634) was opened in Jan 2025,
but merged in Nov 2025. During that time, the sized hierachy PR
(https://github.com/rust-lang/rust/pull/137944) was opened in Mar 2025,
and merged in Jun 2025. The `TrivialClone` PR was not updated to account
for the sized hierachy changes.
core::ptr: deduplicate docs for as_ref, addr, and as_uninit_ref
also add INFO.md file explaining the purpose of the ptr/docs dir, and give some pointers (heh) to future maintainers.
follow up to rust-lang/rust#142101
part of rust-lang/rust#139190
r? `@workingjubilee`
docs(std): add missing closing code block fences in doc comments
This PR adds a few closing code block fences which I believe are missing in some doc comments. It seems that rustdoc just autocloses code blocks at the end of doc comments and thus these were easily overlooked: I do not think these code blocks are special in any way.
I found these when working on a Clippy lint that checks the last sentence of doc comments for terminal punctuation, and these were failing cases when testing against the std. Therefore I am not entirely sure these are all such cases, but still have high hopes that they are (or at least a well-defined subset of them).
Constify conversion traits (part 1)
This is the first part of rust-lang/rust#144289 being split into smaller pieces. It adds/moves constness of several traits under the `const_convert` feature:
* `From`
* `Into`
* `TryFrom`
* `TryInto`
* `FromStr`
* `AsRef`
* `AsMut`
* `Borrow`
* `BorrowMut`
* `Deref`
* `DerefMut`
There are a few methods that are intrinsically tied to these traits which I've included in the feature. Particularly, those which are wrappers over `AsRef`:
* `ByteStr::new` (unstable under `bstr` feature)
* `OsStr::new`
* `Path::new`
Those which directly use `Into`:
* `Result::into_ok`
* `Result::into_err`
And those which use `Deref` and `DerefMut`:
* `Pin::as_ref`
* `Pin::as_mut`
* `Pin::as_deref_mut`
* `Option::as_deref`
* `Option::as_deref_mut`
* `Result::as_deref`
* `Result::as_deref_mut`
(note: the `Option` and `Result` methods were suggested by ``@npmccallum`` initially as rust-lang/rust#146101)
The parts which are missing from this PR are:
* Anything that involves heap-allocated types
* Making any method const than the ones listed above
* Anything that could rely on the above, *or* could rely on system-specific code for `OsStr` or `Path` (note: this mostly makes these methods useless since `str` doesn't implement `AsRef<OsStr>` yet, but it's better to track the method for now and add impls later, IMHO)
r? ``@tgross35`` (who mostly already reviewed this)
The current documentation is not clear whether adding `a` to a pointer overaligns (align up) or underaligns (align down).
It should say this explicitly.
const-eval: full support for pointer fragments
This fixes https://github.com/rust-lang/const-eval/issues/72 and makes `swap_nonoverlapping` fully work in const-eval by enhancing per-byte provenance tracking with tracking of *which* of the bytes of the pointer this one is. Later, if we see all the same bytes in the exact same order, we can treat it like a whole pointer again without ever risking a leak of the data bytes (that encode the offset into the allocation). This lifts the limitation that was discussed quite a bit in https://github.com/rust-lang/rust/pull/137280.
For a concrete piece of code that used to fail and now works properly consider this example doing a byte-for-byte memcpy in const without using intrinsics:
```rust
use std::{mem::{self, MaybeUninit}, ptr};
type Byte = MaybeUninit<u8>;
const unsafe fn memcpy(dst: *mut Byte, src: *const Byte, n: usize) {
let mut i = 0;
while i < n {
*dst.add(i) = *src.add(i);
i += 1;
}
}
const _MEMCPY: () = unsafe {
let ptr = &42;
let mut ptr2 = ptr::null::<i32>();
// Copy from ptr to ptr2.
memcpy(&mut ptr2 as *mut _ as *mut _, &ptr as *const _ as *const _, mem::size_of::<&i32>());
assert!(*ptr2 == 42);
};
```
What makes this code tricky is that pointers are "opaque blobs" in const-eval, we cannot just let people look at the individual bytes since *we don't know what those bytes look like* -- that depends on the absolute address the pointed-to object will be placed at. The code above "breaks apart" a pointer into individual bytes, and then puts them back together in the same order elsewhere. This PR implements the logic to properly track how those individual bytes relate to the original pointer, and to recognize when they are in the right order again.
We still reject constants where the final value contains a not-fully-put-together pointer: I have no idea how one could construct an LLVM global where one byte is defined as "the 3rd byte of a pointer to that other global over there" -- and even if LLVM supports this somehow, we can leave implementing that to a future PR. It seems unlikely to me anyone would even want this, but who knows.^^
This also changes the behavior of Miri, by tracking the order of bytes with provenance and only considering a pointer to have valid provenance if all bytes are in the original order again. This is related to https://github.com/rust-lang/unsafe-code-guidelines/issues/558. It means one cannot implement XOR linked lists with strict provenance any more, which is however only of theoretical interest. Practically I am curious if anyone will show up with any code that Miri now complains about - that would be interesting data. Cc `@rust-lang/opsem`
Add `cast_init` and `cast_uninit` methods for pointers
ACP: rust-lang/libs-team#627
Tracking issue: rust-lang/rust#145036
This includes an incredibly low-effort search to find uses that could be switched to using these methods. I only searched for `cast::<\w>` and `cast::<MaybeUninit` because there would otherwise be way too much to look through, and I also didn't modify anything inside submodules/subtrees.
Jonathan Brouwer