-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate "no UnsafeCell
" property into separate Immutable
trait; allow FromZeros
, FromBytes
, and AsBytes
on types with UnsafeCell
s
#251
Closed
10 of 11 tasks
Tracked by
#671
Labels
compatibility-breaking
Changes that are (likely to be) breaking
Comments
This was referenced Oct 15, 2022
Closed
This was referenced Sep 8, 2023
joshlf
changed the title
Consider separating
Consider separating Oct 12, 2023
FromBytes
and RefFromBytes
(and same for AsBytes
)FromBytes
and RefFromBytes
(and same for AsBytes
) or supporting NoCell
github-merge-queue bot
pushed a commit
that referenced
this issue
Dec 6, 2023
Makes progress on #251
github-merge-queue bot
pushed a commit
that referenced
this issue
Dec 6, 2023
Makes progress on #251
joshlf
added a commit
that referenced
this issue
Dec 6, 2023
TODO: - Require `T: NoCell` and `U: NoCell` in `transmute_ref!` and `transmute_mut!` - Tests - Exercise transmuting `UnsafeCell`s by value - Fix compilation with some `AsBytes` methods - Time to rename `AsBytes` to `ToBytes`? Closes ##251
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Mar 27, 2024
Clarify atomic bit validity The previous definition used the phrase "representation", which is ambiguous given the current state of memory model nomenclature in Rust. For integer types and for `AtomicPtr<T>`, the new wording clarifies that size and bit validity are guaranteed to match the corresponding native integer type/`*mut T`. For `AtomicBool`, the new wording clarifies that size, alignment, and bit validity are guaranteed to match `bool`. Note that we use the phrase "size and alignment" rather than "layout" since the latter term also implies that the field types are the same. This isn't true - `AtomicXxx` doesn't store an `xxx`, but rather an `UnsafeCell<xxx>`. This distinction is important for some `unsafe` code, which needs to reason about the presence or absence of interior mutability in order to ensure that their code is sound (see e.g. google/zerocopy#251).
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Mar 27, 2024
Clarify atomic bit validity The previous definition used the phrase "representation", which is ambiguous given the current state of memory model nomenclature in Rust. For integer types and for `AtomicPtr<T>`, the new wording clarifies that size and bit validity are guaranteed to match the corresponding native integer type/`*mut T`. For `AtomicBool`, the new wording clarifies that size, alignment, and bit validity are guaranteed to match `bool`. Note that we use the phrase "size and alignment" rather than "layout" since the latter term also implies that the field types are the same. This isn't true - `AtomicXxx` doesn't store an `xxx`, but rather an `UnsafeCell<xxx>`. This distinction is important for some `unsafe` code, which needs to reason about the presence or absence of interior mutability in order to ensure that their code is sound (see e.g. google/zerocopy#251).
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 28, 2024
Rollup merge of rust-lang#121943 - joshlf:patch-11, r=scottmcm Clarify atomic bit validity The previous definition used the phrase "representation", which is ambiguous given the current state of memory model nomenclature in Rust. For integer types and for `AtomicPtr<T>`, the new wording clarifies that size and bit validity are guaranteed to match the corresponding native integer type/`*mut T`. For `AtomicBool`, the new wording clarifies that size, alignment, and bit validity are guaranteed to match `bool`. Note that we use the phrase "size and alignment" rather than "layout" since the latter term also implies that the field types are the same. This isn't true - `AtomicXxx` doesn't store an `xxx`, but rather an `UnsafeCell<xxx>`. This distinction is important for some `unsafe` code, which needs to reason about the presence or absence of interior mutability in order to ensure that their code is sound (see e.g. google/zerocopy#251).
joshlf
added a commit
that referenced
this issue
May 9, 2024
This commit adds the `pointer::aliasing_safety::AliasingSafe` trait, which is implemented for pointer conversions which do not violate aliasing. This can happen either because the aliasing is exclusive or because neither type contains `UnsafeCell`s. This paves the way for us to remove `Immutable` bounds from some of our API, including from some derives. Makes progress on #251 Co-authored-by: Jack Wrenn <jswrenn@amazon.com>
joshlf
added a commit
that referenced
this issue
May 9, 2024
This commit adds the `pointer::aliasing_safety::AliasingSafe` trait, which is implemented for pointer conversions which do not violate aliasing. This can happen either because the aliasing is exclusive or because neither type contains `UnsafeCell`s. This paves the way for us to remove `Immutable` bounds from some of our API, including from some derives. Makes progress on #251 Co-authored-by: Jack Wrenn <jswrenn@amazon.com>
joshlf
added a commit
that referenced
this issue
May 9, 2024
This commit adds the `pointer::aliasing_safety::AliasingSafe` trait, which is implemented for pointer conversions which do not violate aliasing. This can happen either because the aliasing is exclusive or because neither type contains `UnsafeCell`s. This paves the way for us to remove `Immutable` bounds from some of our API, including from some derives. Makes progress on #251 Co-authored-by: Jack Wrenn <jswrenn@amazon.com>
joshlf
added a commit
that referenced
this issue
May 9, 2024
There are some APIs which still spuriously require `Immutable`, but which require more work to update. These will be fixed in a separate commit. Makes progress on #251
joshlf
added a commit
that referenced
this issue
May 9, 2024
There are some APIs which still spuriously require `Immutable`, but which require more work to update. These will be fixed in a separate commit. Makes progress on #251 Co-authored-by: Jack Wrenn <jswrenn@amazon.com>
github-merge-queue bot
pushed a commit
that referenced
this issue
May 9, 2024
This commit adds the `pointer::aliasing_safety::AliasingSafe` trait, which is implemented for pointer conversions which do not violate aliasing. This can happen either because the aliasing is exclusive or because neither type contains `UnsafeCell`s. This paves the way for us to remove `Immutable` bounds from some of our API, including from some derives. Makes progress on #251 Co-authored-by: Jack Wrenn <jswrenn@amazon.com>
github-merge-queue bot
pushed a commit
that referenced
this issue
May 9, 2024
* Add `AliasingSafe` framework This commit adds the `pointer::aliasing_safety::AliasingSafe` trait, which is implemented for pointer conversions which do not violate aliasing. This can happen either because the aliasing is exclusive or because neither type contains `UnsafeCell`s. This paves the way for us to remove `Immutable` bounds from some of our API, including from some derives. Makes progress on #251 Co-authored-by: Jack Wrenn <jswrenn@amazon.com> * Remove `Immutable` where it's no longer needed There are some APIs which still spuriously require `Immutable`, but which require more work to update. These will be fixed in a separate commit. Makes progress on #251 Co-authored-by: Jack Wrenn <jswrenn@amazon.com> --------- Co-authored-by: Jack Wrenn <jswrenn@amazon.com>
github-merge-queue bot
pushed a commit
that referenced
this issue
May 10, 2024
Makes progress on #251.
joshlf
changed the title
Separate "no
Separate "no May 18, 2024
UnsafeCell
" property into separate NoCell
trait; allow FromZeros
, FromBytes
, and AsBytes
on types with UnsafeCell
sUnsafeCell
" property into separate Immutable
trait; allow FromZeros
, FromBytes
, and AsBytes
on types with UnsafeCell
s
joshlf
added
the
blocking-next-release
This issue should be resolved before we release on crates.io
label
May 30, 2024
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 8, 2024
Makes progress on #251
joshlf
removed
the
blocking-next-release
This issue should be resolved before we release on crates.io
label
Sep 8, 2024
@korran This is now available stably in our 0.8 release train. |
The sole remaining concern is now in its own issue: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
Introduce a
Immutable
trait which indicates that a type contains noUnsafeCell
s. AllowFromZeros
,FromBytes
, andAsBytes
on types withUnsafeCell
s and useImmutable
as a bound on individual methods/functions.This enables by-value transmutations such as
transmute!
on types containingUnsafeCell
s.See also #694.
Progress
Immutable
traitNoCell
#656Immutable
NoCell
#667FromZeros
,FromBytes
, andAsBytes
onUnsafeCell
; addImmutable
bound on methods as neededNoCell
permitUnsafeCell
s #682AsBytes
toIntoBytes
#695TryFromBytes
,FromZeros
, andFromBytes
for unsizedUnsafeCell
. See the discussion below for why we originally limited these impls to sizedUnsafeCell
s only.TryFromBytes
onUnsafeCell
; addImmutable
bound ontry_from_ref
methodTryFromBytes
] PermitUnsafeCells
#890#[doc(hidden)]
fromImmutable
andpub use zerocopy_derive::Immutable
NoCell
#977Immutable
as merely a polyfill for that traitUnsafeCell
s, but not necessary, and that callers cannot assume thatT: Immutable
implies thatT
contains noUnsafeCell
s. Note that our code will need to rely on this implication, and all safety comments should be updated to point at an issue that tracks this change.Consider adding blanket traits:RefFromZeros
forFromZeros + Immutable
,RefFromBytes
forFromBytes + Immutable
, andRefAsBytes
forAsBytes + Immutable
Immutable
#1296Details
We require that
FromZeros
,FromBytes
, andAsBytes
types don't permit interior mutability. This is a requirement in order for reference casts (e.g.,&T
to&[u8]
or vice-versa) to be valid, but is not a requirement for value casts. As a result, we don't support some transmutations that are sound (namely, value transmutations on types with interior mutability).If we added a separate
Immutable
trait to describe this "has noUnsafeCell
s" property, then we could decouple it from the other traits and allow them to support types withUnsafeCell
s.Immutable
would then be required as a bound on some functions/methods/macros. This would make our API somewhat more complicated, but would unlock a new class of use cases.Note that
Immutable
would be equivalent to the stdlib-internalFreeze
trait. There is a proposal to make that trait public, but we shouldn't bank on that happening any time soon.TryFromBytes
and unsizedUnsafeCell
In principle, there's no reason we couldn't implement
FromZeros
,FromBytes
, andAsBytes
forUnsafeCell<T>
even whenT: ?Sized
. However, this would not play nicely withTryFromBytes
(currently in progress in #5), which we want to eventually be a super-trait ofFromZeros
.In particular, in order to implement
TryFromBytes
for a type, we have to implement theis_bit_valid
method. ForUnsafeCell<T>
whereT: Sized
, we can make a copy of the referentUnsafeCell<T>
, transmute it to aMaybeUninit<T>
, and then construct aPtr<T>
to that value. This workaround isn't possible for unsizedUnsafeCell
s.Given that the whole problem with
UnsafeCell
s arises when they're handled by-reference, and given that the only way to operate on unsized values in Rust (at least today) is by reference, supporting unsizedUnsafeCell
s is unlikely to be useful to any of our users. Thus, by implementingTryFromBytes
(and, by implication, the other traits) only for sizedUnsafeCell
, we get most of the benefit.Motivation
This was originally motivated by chipsalliance/caliptra-sw#634. @korran has provided this minimized example to motivate the feature request:
If
FromBytes
didn't forbid interior mutability, the API offrom_address
would be the same, but it would not require the authors offrom_address
to justify that it's sound to construct aPrng
at the given memory location regardless of its previous contents. Instead, the safety argument can just be "Prng: FromBytes
, so it's sound regardless of the memory contents".The text was updated successfully, but these errors were encountered: