Comments (5)
Option B seems fine if the error message is fixed in a timely manner, which is usually the case (thank you ekuber and co <3).
If the issue lingers we can go with Option A if we have to.
Since this doesn't actually block Pod from being implemented manually then it's probably fine to wait a little longer.
from bytemuck.
This seems accurate, if the generic is also Pod of course.
Edit: I would accept a PR for this but I am unlikely to do it myself because I'm not that big on proc-macros.
from bytemuck.
I have a patch for this: main...LukasKalbertodt:relax-derives-for-generics
The reason why I did not submit this as PR (yet) is because it makes a specific error messages notably worse: if a field's type does not implement Zeroable
/Pod
, the current error is something like this:
error[E0277]: the trait bound `Bar: Zeroable` is not satisfied
--> src/main.rs:6:10
|
6 | bar: Bar,
| ^^^ the trait `Zeroable` is not implemented for `Bar`
|
note: required by a bound in `assert_impl`
--> src/main.rs:4:10
|
4 | #[derive(Zeroable)]
| ^^^^^^^^ required by this bound in `assert_impl`
5 | struct Foo {
| ------ required by a bound in this
= note: this error originates in the derive macro `Zeroable` (in Nightly builds, run with -Z macro-backtrace for more info)
With this change, the error is:
error[E0277]: the trait bound `Bar: bytemuck::zeroable::Zeroable` is not satisfied
--> examples/test.rs:4:23
|
4 | #[derive(Clone, Copy, Zeroable, Pod)]
| ^^^^^^^^ the trait `bytemuck::zeroable::Zeroable` is not implemented for `Bar`
|
= help: see issue #48214
This is basically due to this: rust-lang/rust#90869 (I just reported this issue).
So, how to proceed?
- (a) Declare this error message unimportant and merge my changes now already
- (b) Wait for the Rust diagnostic issue to be fixed
- (c) Change my patch to only include the worse error message in the generic cases. This would be possible, doesn't make anything that works today worse, but would have more code and still has bad error messages for the generic case.
from bytemuck.
fixed in a timely manner, which is usually the case (thank you ekuber and co <3).
Hui, it was indeed fixed very quickly. Those people are amazing!
I will soon submit my changes as PR. Whenever I get to it. I guess it's fine to still wait a bit, maybe until the fix is on stable or so.
from bytemuck.
Nice work! A further relaxation might be type-layout,
I believe that the restrictions can be relaxed a little more to all non zero sized types have the same type.
there is this note, however I don't see how it applies to repr(C)
.
C++, in contrast, gives empty structs a size of 1
Since it seems relatively related, I thought I might mention it here, but should open up a different issue unless I'm missing something.
from bytemuck.
Related Issues (20)
- Allow deriving `Pod` for structs where generics are used only as `PhantomData` HOT 2
- Derive macro doesn't work when exported HOT 1
- Fails to compile with rustc 1.72.0-nightly (fe7454bf4 2023-06-19) HOT 8
- Raw pointer cast functions HOT 4
- Cannot use derive macros when reexporting bytemuck from library HOT 2
- Crate makes assumptions about bool values HOT 5
- Safe `offset_of` for packed structs using `addr_of`? HOT 9
- `ASSERT_SIZE_MULTIPLE_OF` when casting `&[u8]` to `&[[u8; 16]]` HOT 1
- Crate documentation is misleading, implies `Pod` required for all functions. HOT 3
- the `FooBits` type generated by `#[derive(CheckedBitPattern)]` should implement `NoUninit` if `Self` is `NoUninit` HOT 3
- False positive derive error for `TransparentWrapper` around types like `Box` HOT 1
- Potential rustc bug related to deriving ByteEq HOT 2
- no-uninit trait with interior mutability HOT 6
- Deriving Pod for arbitrary generic types HOT 1
- Why use from_bytes when you can use pod_read_unaligned? HOT 5
- Build error on nightly-2024-02-05 HOT 1
- Bytemuck 1.14.2 does not build on stable HOT 1
- Feature request: Casting owned slices or vec, I.e. Box<[u64]> to Box<[u8]> or Vec<u64> to Vec<u8> HOT 4
- conversion from `&[u8]` to `&[T]`? HOT 4
- Allow deriving `Zeroable` for enums which are `#[repr(u32, i8, etc..)]` HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bytemuck.