d10fbfc6ff
* simplify `ToTokens` impl for `Representation` Instead of collecting the representation and modifier into `Option`s and determining whether a comma is needed manually, we can use the `Puncutuated` struct which handles commas automatically. This will also make emitting the `align` modifier in the future easier. * emit alignment modifier This is required for correctly implementing `CheckedBitPattern` because we need the layout of the type and its `Bits` type to have the same layout. * add unit test for `#[repr]` parsing * allow multiple alignment modifiers According to RFC #1358, if multiple alignment modifiers are specified, the resulting alignment is the maximum of all alignment modifiers. * actually return the error we just created * factor out the integer Repr's into their own type This is a preparation step for adding support for `#[repr(C, int)]`. * allow parsing `#[repr(C, int)]` This can be used on enums with fields. * derive `CheckedBitPattern` for enums with fields The implementation mostly mirrors the desugaring described at https://doc.rust-lang.org/reference/type-layout.html * add comments and rename some idents * update error message * update docs for `CheckedBitPattern` derive * add new nested test case, change generated type naming scheme * fix wrong comment * small nit --------- Co-authored-by: Gray Olson <gray@grayolson.com> |
||
|---|---|---|
| .cargo | ||
| .github | ||
| derive | ||
| src | ||
| tests | ||
| .gitignore | ||
| Cargo.toml | ||
| changelog.md | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| LICENSE-ZLIB | ||
| pedantic.bat | ||
| README.md | ||
| rustfmt.toml | ||
bytemuck
A crate for mucking around with piles of bytes.
This crate lets you safely perform "bit cast" operations between data types. That's where you take a value and just reinterpret the bits as being some other type of value, without changing the bits.
- This is not like the
askeyword - This is not like the
Fromtrait - It is most like
f32::to_bits, just generalized to let you convert between all sorts of data types.
Here's the part you're more likely to care about: you can do this with slices too!
When a slice is involved it's not a direct bitcast. Instead, the cast_slice
and cast_slice_mut functions will pull apart a slice's data and give you a new
slice that's the same span of memory just viewed as the new type. If the size of
the slice's element changes then the length of the slice you get back will be
changed accordingly.
This lets you cast a slice of color values into a slice of u8 and send it to
the GPU, or things like that. I'm sure there's other examples, but honestly this
crate is as popular as it is mostly because of Rust's 3D graphics community
wanting to cast slices of different types into byte slices for sending to the
GPU. Hi friends! Push those vertices, or whatever it is that you all do.
See Also
While bytemuck is full of unsafe code, I've also started a "sibling crate"
called bitfrob, which is where
operations that are 100% safe will be added.
Stability
- The crate is 1.0 and I consider this it to be "basically done". New features
are usually being accepted when other people want to put in the work, but
myself I wanna move on to using
bytemuckin bigger projects. - The default build of the
bytemuckcrate will continue to work withrustc-1.34for at least the rest of the1.y.zversions. - Any other cargo features of the crate are not held to the same standard, and may work only on the latest Stable or even only on latest Nightly.
Future Plans: Once the Safe Transmute Project completes and
stabilizes ("eventually") this crate will be updated to use that as the
underlying mechanism for transmutation bounds, and a 2.0 version of bytemuck
will be released. The hope is for the 1.0 to 2.0 transition to be as seamless as
possible, but the future is always uncertain.