[feature request] support for custom derive

[yshui]

There are some quality-of-life derives that would be really nice to have for C++ types. e.g. #[derive(TryFromPrimitive)] from num_enum.

Maybe generate! could take a list of derives that user want to add?

[adetaylor]

I'm interested in trying to achieve support for derives. I'd accept pull requests here, but I'd recommend sketching out a bit more of a design first to avoid wasted time. (Please don't use generate!. Instead use a separate directive, e.g. derive!, because there are some modes in which generate! doesn't get used.)

[yshui]

So something similar to derive!("type", "derive1", "derive2", ...)?

[adetaylor]

I think so, yes. Things to think about:

• autocxx tends to build on the features which cxx has. cxx has support for some standard library derives, and occasionally takes PRs which adds extra derives (e.g. https://github.com/dtolnay/cxx/pull/889). Because we are using the ExternType feature of autocxx we can generally get away with adding the derives to the versions of the types within our bindgen sub-module, so I don't think it's strictly a requirement that cxx knows about the derives we're using, but we should be careful. If cxx hasn't added arbitrary derive support, there might be a good reason, and we should follow suit unless we can demonstrate why things are different in the autocxx circumstance.
• We would need to think carefully about how/whether to add these derives to autocxx's built-in types (e.g. c_int) or to cxx's (e.g. UniquePtr<T>, which probably isn't possible)
• Similarly, bindgen supports a fixed set of derives (see here). I don't know why bindgen doesn't provide a means to request arbitrary derives - it seems like an obvious thing for people to want. I think I'd want to poke around in their git & github issue history to see if there's a good reason, before we deviate from their practice.
• Some derives take helper attributes, so the derive! support would need to handle that (or at least make sure it's possible to extend in that direction in the future).
• For derives outside of the Rust standard library, our generated bindings would now depend on an external crate. I think we might want a command line option to autocxx_gen which prevents this and produces an immediate codegen error, instead of revealing such dependency errors later in the build process. I haven't thought through whether this is really necessary or not.
• Presumably if things like autocxx::c_int also gain derives, then autocxx itself will come to depend on those external crates. We would want an arrangement of features to make these dependencies optional, which will be sadly messy.

[yshui]

Very good points.

As for

Similarly, bindgen supports a fixed set of derives...

I had a look, there is a issue for this https://github.com/rust-lang/rust-bindgen/issues/1089. And actually this feature has recently been added to bindgen, via parse_callbacks

[adetaylor]

Ah great!

[tom-anders]

So what's the status of this currently? Does autocxx allow passing callbacks to bindgen?