derive(Debug) for translated types

[dgherzka]

It would be great if translated types could implement Debug. Is this something that others might be interested in?

[dgherzka]

I put up a PR for this, but I'm not sure how sound it is: #1040

[kkysen]

It would be great if translated types could implement Debug. Is this something that others might be interested in?

It would be pretty easy to do this post-transpilation by just replacing #[derive(Copy, Clone)] with #[derive(Copy, Clone, Debug)], though it doesn't work for unions as you encountered in #1040. Optionally deriving other traits, and often for non-union types, is more generally useful, though, besides just for Debug, so I think this idea is good. For example, #[derive(Default)] would be helpful and should be possible for all #[repr(C)] types (I'm not sure it works automatically for unions, but an impl Default for Union could be written automatically). And there are other traits that would be useful, like ones from bytemuck.

[dgherzka]

Yeah, I was originally thinking of just doing this post-transpilation, but that seemed brittle, and it wouldn't be great to have to redundantly check for unions after the transpile.

I like the idea of supporting other derives. Maybe instead of being a boolean flag, it can be an option that takes a list of traits. I would be concerned, though, that if different traits have different requirements, that could lead to unexpected results. For example, if someone specifies --derive Debug,Default, a struct containing a union would derive only Default. I guess that's already the case for structs containing va_lists since those are automagically not Clone or Copy. Would it make sense to add comments by struct decls like // This struct cannot derive Debug because it contains a union, // This struct cannot derive Clone or Copy because it contains a va_list, etc.?

[dgherzka]

Another idea I had was to allow the C data types to be annotated with the traits to derive. My understanding is that this would be difficult to do because it's difficult to attribute comments to AST elements. Is that correct? Is there some other way the AST could be annotated?

(This wouldn't actually be helpful for my use case, but now I'm curious)

[kkysen]

Another idea I had was to allow the C data types to be annotated with the traits to derive. My understanding is that this would be difficult to do because it's difficult to attribute comments to AST elements. Is that correct? Is there some other way the AST could be annotated?

(This wouldn't actually be helpful for my use case, but now I'm curious)

Yeah, most things (including types) can have annotations in C with __annotation__((packed)), for example. Some of those annotations we read and use, such as packed, and there are many others we should use but don't yet, like nonnull. I'm not sure how custom attributes work, but there's probably a way, so something like this could potentially be done.