Information discarded by bindgen which we need (tracker bug)

[adetaylor]

bindgen doesn't pass on quite all the information we need in order to be able to generate autocxx bindings. Options in the future might be to fork bindgen, ask very nicely if they mind us upstreaming patches to add metadata, or switch away from bindgen and use llvm directly.

In any case this bug will be a live tracker of all known cases where we don't have all the information that we require about the underlying C++.

• Classes vs structs. Both present as structs in the bindgen output. When we then generate extra C++ we have to plump for one or the other. In some ABIs this will result in a binary incompatibility or failure to compile. Per Classes result in build warnings; build failure on Windows #54.
• Overloaded methods vs methods ending in digits. Two methods a(uint32_t) and a(uint8_t) will be output as a and a1. There is no way for us to distinguish that from methods really called a and a1. Worse, this is across all the types in a namespace, so MyStruct::a and MyOtherStruct::a become MyStruct::a and MyOtherStruct::a1.
• Nested types. A struct nested inside another struct is not noted in the bindgen output, so we can't generate compatible C++ code - Nested types don't work #115.
• Private constructors. Per Types without constructors do not gain a make_unique #122.
• Pointers vs references. Per Handle pointers #102.
• Virtual functions. Per Support calling virtual functions #195 and Allow calling pure virtual functions #305.
• When template params are unused, per Gracefully avoid cases where template parameters are skipped #414 and Skip cases where references to template parameters are skipped #416.
• Deleted functions, per Don't generate bindings for deleted functions #426.

[martinboehme]

• Classes vs structs. Both present as structs in the bindgen output. When we then generate extra C++ we have to plump for one or the other. In some ABIs this will result in a binary incompatibility or failure to compile.

Not sure I understand -- I always thought a struct was exactly identical to a class, just that it has public visibility by default? And I believe it's legal for forward declarations of a struct to use class and vice versa (see this StackOverflow answer). I'm pretty sure there isn't an ABI difference either. Or am I misunderstanding what you're referring to here?

[adetaylor]

This is #54 - let's discuss over there.

[martinboehme]

Thanks for the clarification -- interesting!

[adetaylor]

For #414 and #102 many types have 'annotations' attached (the RustTy type in our fork of bindgen). Such annotations are currently discarded using an ignore_annotations method. Each time that happens, it's probably a bug. For example this means we would try (and fail) to generate POD struct fields using types with template parameters which bindgen has dropped. Once a plan presents itself here, we should ensure we never drop information like this.

[martinboehme]

Note from #426: The Rust function signature for copy constructors and move constructors is the same, so bindgen needs to add an annotation that allows us to distinguish between them.

[bsilver8192]

#799 is also on this list, and I'm pretty sure #815 is too.