-
Notifications
You must be signed in to change notification settings - Fork 744
Make derive Debug configurable for specific structures #1491
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
Comments
This should be possible and not too hard. We have per-item annotations, and very similar code to control whitelisting / blacklisting. I'd be happy to help writing / review a patch implementing something like this. |
(Sorry for the lag btw! :/) |
Though the suggested feature can solve the problem, the issue seems to be solved in different way. For now, deriving for any packed struct is warnings and it seems it is going to be errors in future. So than, when users are putting I suggest to ignore |
It appears that this is now becoming more urgent; I didn't find the precise nightly this changed in (or whether it's really a nightly change, probably it is), but the warnings are now errors:
[edit: It is already an error on 2022-04-25, and was still a warning in 2022-03-08] |
It doesn't, but shifts them -- now I'm getting impl ::core::fmt::Debug for ble_hci_cmd {
fn fmt(&self, f: &mut ::core::fmt::Formatter<'_>) -> ::core::fmt::Result {
write!(
f,
"ble_hci_cmd {{ opcode: {:?}, length: {:?}, data: {:?} }}",
self.opcode, self.length, self.data
)
}
} For some fields the workaround (recommended variously around the issue) of putting values in blocks helps write!(
f,
"ble_hci_cmd {{ opcode: {:?}, length: {:?}, data: {:?} }}",
{ self.opcode } , { self.length }, { self.data }
) but not for all, eg. (in this case) data is not Copy:
for which the best I managed was to just leave it out (in the test where I manually modified the bindgen output, I put Should I open up a separate issue about the generated Derive code not working well for packed structs, or do we keep tracking this here? |
I can't work on a full PR right now, but in case I come back to this: all code is in |
@chrysn It would be fine with me if you created a separate issue for that (including your helpful detail in #1491 (comment)), since the current issue is an enhancement request, and what you are describing is really a bug. Thanks! |
I noticed that this issue looks like the same thing as #961. Maybe one of them can be closed as a duplicate of the other. |
It's not quite the same. #961 can certainly be a workaround: the user notices that some Debug fails, and blocks that from being derived. But the better behavior (and also the compatible one, considering the failure to derive Debug from where it previously worked) is for bindgen to provide some Debug implementation when requested through impl_debug. Tracking now at #2221. |
I was not clear. I think the title of this issue ("Make derive Debug configurable for specific structures") and the original description ("We would like to be able to specify structures for which we want derive debug to be excluded...") are the same as #961 ("Allow specifying certain types we shouldn't derive/impl Debug for"). I agree with you that your particular issue is different -- thanks for filing #2221. |
Input C/C++ Header
Bindgen Invocation
Actual Results
Compilation Warning:
Nice to have behaviour
We would like to be able to specify structures for which we want derive debug to be excluded (for example
virtio_net_ctrl_mac
) so we can automatically generate bindings. Our workaround right now is to manually remove the debug derive.The text was updated successfully, but these errors were encountered: