-
Notifications
You must be signed in to change notification settings - Fork 11
derive(Pwrite) doesn't compile for structs with non-Copy fields #15
Comments
Unfortunately changing the proc macro implementations to use
This probably isn't hard to fix, though. |
This should help in fixing m4b/scroll_derive#15 .
This should help in fixing m4b/scroll_derive#15 .
I have a simple patch that uses references, and atop m4b/scroll#35 it works. |
Man, what a horrible bug :/ Maybe we/I should have just made pwrite take a reference to self instead of the owned value? That would technically be a breaking change, but also perhaps it's better to be flexible and allow both? In meantime, merging your reference patch should be backwards compatible and will be fine if decide to only take reference to self in pwrite, so probably just merge that? |
I dunno! Obviously I'm trying to do things that are sort of outside of your original design. For structs composed of just primitive fields this all works fine!
I don't think it should harm anything, no. |
will work with non-`Copy` types. Fixes m4b#15
This should help in fixing m4b/scroll_derive#15 .
I ran into this while trying to test something else, but it's definitely going to bite me in the future. Here's a simple example:
This code fails to compile with this error:
The expanded impls for
B
look like:Removing the
#[derive(Pwrite)]
and pasting that code inline gives a more precise error:Changing that line to borrow instead fixes this:
dst.gwrite_with(&self.a, offset, ctx)?;
. I haven't checked to see if that has a negative impact on the generated code, but since theTryIntoCtx
impl forT
already forwards to&T
I can't imagine it'd make a difference.The text was updated successfully, but these errors were encountered: