-
Notifications
You must be signed in to change notification settings - Fork 81
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
Comments
FromBytes
and RefFromBytes
(and same for AsBytes
)FromBytes
and RefFromBytes
(and same for AsBytes
) or supporting NoCell
Makes progress on #251
Makes progress on #251
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
Reopening; we still need to allow |
@korran Just wanted to let you know that this is available in 0.8.0-alpha.1. The |
Will this work also enable some zerocopy functionality for Atomic* types? |
Good point! I've filed #1009 to track. |
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).
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).
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).
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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
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 <[email protected]>
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 <[email protected]>
* 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 <[email protected]> * 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 <[email protected]> --------- Co-authored-by: Jack Wrenn <[email protected]>
Makes progress on #251.
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
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
#695UnsafeCell
FromZeros
,FromBytes
, andAsBytes
for unsizedUnsafeCell<T>
(ie, whereT: ?Sized
). This causes problems forTryFromBytes
, and so we've decided to restrict toT: Sized
(see the discussion below).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: