-
Notifications
You must be signed in to change notification settings - Fork 711
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
Derive Clone when deriving Copy #934
Comments
This is pretty much intentional, because of large arrays, which implement |
Well, certainly this is at worst a wart rather than a bug. I don't really expect auto-generated code to be clean under clippy. (But wouldn't it be nice if it were?). Compared to the work you must already do figuring out when all the other derived things are derivable, I'd have guessed that "is there a big array involved?" was a relatively straightforward check... but that's absolutely a guess from ignorance, and I'm happy to be contradicted by someone who actually knows what they're talking about! So yeah, I'm content to defer to maintainer judgement here. If you think that the effort / reward ratio for this one will never be worthwhile, please just close it out. |
Is this the only case where we end up manually implementing |
No: |
Huh. This doesn't sound right. It seems like I don't have the full picture here, and we need some more investigation. |
IIUC, as of Rust 1.21 and rust-lang/rust#43690, large arrays should no longer be an issue when deriving
|
Awesome :) We will need to add a new |
bindgen almost always implements
Clone
explicitly, like this:I (accidentally!) ran clippy over some autogenerated code and it expressed disappointment that
Clone
was manually implemented for all sorts of structures on whichCopy
was derived:And indeed,
Clone
could be derived in every case, at least for my project.The code that prevents this is here.
My input header is a plain C header (so certainly no templates). If anything, it almost looks as though that test is exactly backwards, though I expect it's more likely that I simply don't understand what issue is being avoided here...
Anyway, it certainly seems like
Clone
could be derived a lot more often than it currently is.The text was updated successfully, but these errors were encountered: