rust-bindgen
rust-bindgen copied to clipboard
rust-lang
Allow custom derives and attributes
Several times I found myself in need to derive traits that are not autogenerated by bindgen, and, unfortunately, Rust doesn't allow to put a derive directive (or any attribute) at distance from the original type, even in the same file.
Would it make sense to provide ability to add custom derives or even any attributes to generated types via ParseCallbacks or some other mechanism?
This seems like a good feature to have.
I'd prefer not using ParseCallbacks if possible, because avoiding them allows easier testing, and I believe that custom derives is specific enough that it doesn't need the open ended programmatic access that ParseCallbacks provides.
As far as CLI syntax: --custome-derive '<trait>=<regex>'?
@fitzgen Thing is, some derives still accept options via extra attributes (for example, https://github.com/kwohlfahrt/enum-tryfrom), so I'm not sure if it's worth locking up to just trait name. Maybe accept a raw "header" string to prepend to the type definition? Or at least attribute value, and then "derive" is just one of attribute types like --prepend-attr 'derive(Default)=<regex>'.
Good catch. I guess that it does make sense to have an escape hatch for more complicated cases in ParseCallbacks -- but I'd still prefer the simple versions to be supported on the CLI for easier testing (and in general it is best when things are usable in either scenario).
What do you think about the attribute approach then? (allowing any attributes to be appended) Should be still CLI compatible while allowing these more complex cases.
Sorry I totally thought throught that stuff in my head and then failed to leave any comment about it :-p
The problem is that we would need to parse arbitrary attributes to know which = we are splitting on between the attr and the regex. This is because of attrs like #[serde(rename = "blah")]. I guess we could use https://dtolnay.github.io/syn/syn/fn.parse_outer_attr.html, but that signature doesn't seem to allow trailing bits or return where the parsing ended...
@fitzgen Maybe could use some other delimiter then, like "=>" or whatever?
Or, actually, could as well put the regexp first and start at "#" then like regex#[derive(Default)] or regex=#[derive(Default)] or even just regex=derive(Default) avoiding '#' completely.
Looking for this as well, willing to work on it -- has any work since been done?
I don't think there has been much progress here, but I don't think this should be particularly hard to implement, happy to help.
I want my derive to apply to all structs, which would simplify the implementation for me. Perhaps I can implement that and leave it open to be extended to a regex?
It would be nice, if it would work with enums too. If I'm right then the current implementation of #2059 does only work with structs, or does it?
It would be nice, if it would work with enums too. If I'm right then the current implementation of #2059 does only work with structs, or does it?
I agree, it doesn't seem to work.
