| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
is FFI safe
This allows types like Option<NonZeroU8> to be used in FFI without triggering the improper_ctypes lint. This works by changing the is_repr_nullable_ptr function to consider an enum E to be FFI-safe if:
- E has no explicit #[repr(...)].
- It only has two variants.
- One of those variants is empty (meaning it has no fields).
- The other variant has only one field.
- That field is one of the following:
- &T
- &mut T
- extern "C" fn
- core::num::NonZero*
- core::ptr::NonNull<T>
- #[repr(transparent)] struct wrapper around one of the types in this list.
- The size of E and its field are both known and are both the same size (implying E is participating in the nonnull optimization).
|
|
remove confusing remarks about mixed volatile and non-volatile accesses
These comments were originally added by @ecstatic-morse in https://github.com/rust-lang/rust/commit/911d35f0bfd207112806eaec2763201dad06d1c7 and then later edited by me. The intention, I think, was to make sure people do both their reads and writes with these methods if the affected memory really is used for communication with external devices.
However, [people read this as saying that mixed volatile/non-volatile accesses are UB](https://github.com/rust-lang/rust/issues/58599#issuecomment-493791130), which -- to my knowledge -- they are not. So better remove this.
Cc @rkruppe @rust-lang/wg-unsafe-code-guidelines
|
|
|
|
|
|
|
|
const-stabilize NonNull::dangling and NonNull::cast
|
|
Revert "Disable big-endian simd in swap_nonoverlapping_bytes"
This reverts commit 77bd4dc65406ba3cedbc779e6f6280868231912e (#43159).
Issue #42778 was formerly easy to reproduce on two big-endian targets,
`powerpc64` and `s390x`, so we disabled SIMD on this function for all
big-endian targets as a workaround.
I have re-tested this code on `powerpc64` and `s390x`, each with the
bundled LLVM 8 and with external LLVM 7 and LLVM 6, and the problems no
longer appear. So it seems safe to remove this workaround, although I'm
still a little uncomfortable that we never found a root-cause...
Closes #42778.
r? @arielb1
|
|
This is similar to `NonNull::cast`.
Compared to the `as` operator (which has a wide range of meanings
depending on the input and output types), a call to this method:
* Can only go from a raw pointer to a raw pointer
* Cannot change the pointer’s `const`ness
… even when the pointed types are inferred based on context.
|
|
This reverts commit 77bd4dc65406ba3cedbc779e6f6280868231912e.
Issue #42778 was formerly easy to reproduce on two big-endian targets,
`powerpc64` and `s390x`, so we disabled SIMD on this function for all
big-endian targets as a workaround.
I have re-tested this code on `powerpc64` and `s390x`, each with the
bundled LLVM 8 and with external LLVM 7 and LLVM 6, and the problems no
longer appear. So it seems safe to remove this workaround, although I'm
still a little uncomfortable that we never found a root-cause...
|
|
Closes #44488
|
|
|
|
|
|
|
|
|
|
closes #56286
|
|
Make `ptr::eq` documentation mention fat-pointer behavior
Resolves #59214
|
|
adjust MaybeUninit API to discussions
uninitialized -> uninit
into_initialized -> assume_init
read_initialized -> read
set -> write
|
|
|
|
Link to PhantomData in NonNull documentation
|
|
|
|
uninitialized -> uninit
into_initialized -> assume_init
read_initialized -> read
set -> write
|
|
|
|
|
|
|
|
Resolves #59214
|
|
Note that NonNull does not launder shared references for mutation
See https://users.rust-lang.org/t/relative-pointer-an-abstraction-to-build-movable-self-referential-types/26186/6
|
|
|
|
|
|
|
|
Make `Unique::as_ptr`, `NonNull::dangling` and `NonNull::cast` const
|
|
Make `Unique::as_ptr` const without feature attribute as it's unstable
Make `NonNull::dangling` and `NonNull::cast` const with `feature = "const_ptr_nonnull"`
|
|
|
|
|
|
|
|
|
|
This reverts commit 722b4d695964906807b12379577bce5ee3d23e08, reversing
changes made to 956dba47d33fc8b2bdabcd50e5bfed264b570382.
|
|
|
|
|
|
This is just a copy-paste error.
|
|
Instead, use `#[rustc_layout_scalar_valid_range_start(1)]` directly
on relevant libcore types.
|
|
|
|
Make `const unsafe fn` bodies `unsafe`
r? @Centril
Updated for tracking issue discussion https://github.com/rust-lang/rust/issues/55607#issuecomment-445882296
|
|
Allow ptr::hash to accept fat pointers
Fat pointers implement Hash since #45483. This is a follow-up to #56250.
|
|
VecDeque: fix for stacked borrows
`VecDeque` violates a version of stacked borrows where creating a shared reference is not enough to make a location *mutably accessible* from raw pointers (and I think that is the version we want). There are two problems:
* Creating a `NonNull<T>` from `&mut T` goes through `&T` (inferred for a `_`), then `*const T`, then `NonNull<T>`. That means in this stricter version of Stacked Borrows, we cannot actually write to such a `NonNull` because it was created from a shared reference! This PR fixes that by going from `&mut T` to `*mut T` to `*const T`.
* `VecDeque::drain` creates the `Drain` struct by *first* creating a `NonNull` from `self` (which is an `&mut VecDeque`), and *then* calling `self.buffer_as_mut_slice()`. The latter reborrows `self`, asserting that `self` is currently the unique pointer to access this `VecDeque`, and hence invalidating the `NonNull` that was created earlier. This PR fixes that by instead using `self.buffer_as_slice()`, which only performs read accesses and creates only shared references, meaning the raw pointer (`NonNull`) remains valid.
It is possible that other methods on `VecDeque` do something similar, miri's test coverage of `VecDeque` is sparse to say the least.
Cc @nikomatsakis @Gankro
|
|
|
|
|
|
Fix the just-introduced ptr::hash docs
Follow-up to #56250.
|
|
|
|
|
