Merge header-translator into bindgen #729
Description
I started header-translator as a separate project from bindgen, partly because I needed to learn the libclang API (and then it was easier to start from scratch), but mostly for higher development velocity. See #85.
Nowadays, it now supports most Apple frameworks, and is in that sense "feature complete". So now it might make sense to consider merging header-translator into bindgen's nascent Objective-C support.
Apart from the Objective-C support, there are a number of very important things that I believe header-translator brings to the table compared to bindgen, and that I'd want bindgen to have as well in the end:
- A strong focus on ahead-of-time generation.
- Including e.g. a sidecar file
translation-config.tomlthat allows modifying what's being generated.
- Including e.g. a sidecar file
- Uses Clang/C++ modules to emit things in a more file-by-file manner.
- Also avoids including dependent headers, and instead import
libc/objc2/objc2-*definitions.
- Also avoids including dependent headers, and instead import
- Uses nullability/lifetime/... attributes.
- Automatic memory management.
I suspect that it might make sense to discuss with the bindgen maintainers, perhaps make a vision document or something, before beginning this work in earnest.
Extra notes
See previous discussion in #345 for an alternate route we could take.
We should also keep an eye on -fbounds-safety, and consider building tooling to enable running bindgen once for a bunch of different architectures/platforms, and merge the result, ala #408.
Note that we're currently very hackily parsing a lot of attributes from macro invocations, but when doing this work, it would probably make sense to try to modify upstream libclang to expose these as proper AST nodes (with all of the difficulty inherent in that).
This would allow users to link against private / non-Apple controlled Objective-C frameworks (see e.g. #501).