Regenerate LLVMSharp using unsafe bindings. #105
This is the same as microsoft/ClangSharp#69.
This does, as a part of that, drop support for the
I do think that having better bindings (that more closely mirror the LLVM C++ API) is very useful (I did something similar in ClangSharp here: https://github.com/microsoft/ClangSharp/tree/master/sources/ClangSharp.PInvokeGenerator/Types).
However, with the regeneration here, practically the entire
As the person who added it to start, are you comfortable with the APIs being removed for the time being and being replaced with a lighter-weight wrapper in some future PR?
I believe most of the functionality, modulo mirroring the C++ type hierarchy, is exposed in the lower-level wrapper types (e.g.
A future PR could then expose the higher-level class wrappers again, but this time calling into the low-level wrappers for the supported functionality. This would essentially give you three levels of use:
Regarding the current
So, from a user perspective, I would like to eventually have the "good" parts of it (either in the C++-like API or in the marshalled API), without the shortcomings that we currently have.
(And, of course, let me know if I can help in any way!)
It's worth noting that for the simple-wrapper, a lot of the "niceties" you wanted will still be supported with the simple wrapper.
For example, the simple wrapper types implement
If you wanted to help with redoing the higher level wrapper, I'd be happy to help review/etc.
If you look at
Namely, you have the raw API in
The minimal wrapper uses
There is then the "one step higher" wrapper in
Given that this final tier is using classes, it also has some logic when creating instances to cache things (so we don't create a new instance every time you want to retrieve a property) and for splitting out methods/properties to only be exposed where they make sense (e.g. getting the