You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If two slice DSTs have the same slice offset, element size, and alignment, then we can support transmute_ref! and transmute_mut! for these types - just need to figure out how to encode all of these in the type system (e.g. associated types on KnownLayout)
As part of a broader trend towards teaching zerocopy to express more powerful transmutations, could we add trait AsInitialized<T>? We could use it to replace the existing Src: IntoBytes bound in transmute!, try_transmute!, etc
Support transmuting T to MaybeUninit<T> (or maybe even MaybeUninit<U>) even when T: ?IntoBytes
Once generic_const_exprs and associated_const_equality are stabilized, we can use KnownLayout::LAYOUT to guarantee layout equality, supporting both size equality and slice DST equality (e.g., T: KnownLayout, U: KnownLayout<LAYOUT = {T::LAYOUT}>); see playground example
Add Unalign::replace or swap (which returns the original) and maybe deprecate Unalign::set. Strictly more powerful.
In Ptr's internal invariants, do we need to separately say that the pointer is derived from a valid allocation and that it has provenance for that allocation? Is the latter alone sufficient?
When deriving TryFromBytes, if we're deriving it thanks to #[derive(FromBytes)], emit an empty is_bit_valid impl; this will be more optimizable, and should cut down on compile times
In CI, confirm that MSRV is lower than any version we use for version detection. This will naturally trigger us to clean up the codebase when we bump MSRV.
Only generate roll PRs (for pinned stable and nightly toolchains) on week days
Allow setting repository-wide "vacation mode" that causes rollers to pause
This issue tracks ideas which we might want to tackle some day, but which don't have enough detail to warrant their own separate issues.
Feature additions
transmute_ref!
andtransmute_mut!
for these types - just need to figure out how to encode all of these in the type system (e.g. associated types onKnownLayout
)trait AsInitialized<T>
? We could use it to replace the existingSrc: IntoBytes
bound intransmute!
,try_transmute!
, etcRef
to change the type parameter (ie, perform a transmutation); we could use this to makenew_sized
a thin wrapper aroundnew
NonZero<T>
T
toMaybeUninit<T>
(or maybe evenMaybeUninit<U>
) even whenT: ?IntoBytes
generic_const_exprs
andassociated_const_equality
are stabilized, we can useKnownLayout::LAYOUT
to guarantee layout equality, supporting both size equality and slice DST equality (e.g.,T: KnownLayout, U: KnownLayout<LAYOUT = {T::LAYOUT}>
); see playground exampleUnalign::replace
orswap
(which returns the original) and maybe deprecateUnalign::set
. Strictly more powerful.Safety
&slice[0] as *const
per rust-lang/unsafe-code-guidelines#134&mut as *const
per rust-lang/rust#56604 - see also rust-lang/clippy#12791Ptr
's internal invariants, do we need to separately say that the pointer is derived from a valid allocation and that it has provenance for that allocation? Is the latter alone sufficient?Performance
TryFromBytes
, if we're deriving it thanks to#[derive(FromBytes)]
, emit an emptyis_bit_valid
impl; this will be more optimizable, and should cut down on compile timesis_bit_valid
when possible #1303Developer experience
cargo nextest
to speed up CI execution timescargo release
Documentation
package.metadata.docs.rs.targets
Cargo.toml
key (see e.g. usage in syn)?Testing
kani::cover!
to more thoroughly test Derive trivialis_bit_valid
when possible #1303Miscellaneous
n
bytes long:fn take_bytes<'a>(&mut self, n: Usize<'a>) -> Option<Bytes<'a>>
Cargo.toml
once that's stable on our MSRV: Tracking Issue for[lints]
table RFC 3389 rust-lang/cargo#12115freeze
API once it lands/stabilizes: RFC: Addfreeze
intrinsic and related library functions rust-lang/rfcs#3605const
in zerocopy? Stabilise inline_const rust-lang/rust#104087slice_flatten
?Done
main
at google.github.io/zerocopycargo doc
to GitHub Pages #1227The text was updated successfully, but these errors were encountered: