This is an initial set of LLVM DIBuilder APIs that can create builders,
compile units, files, and scopes, and introspect the debug info inside modules.
Ideally we'd like to have some test with this. The way it is usually done is to use the echo test: it reads a module using the C API and then recreate another identical module using the same C API. This ensure end to end testing. However this doesn't provide any reading facility so that me be more work than you are willing to put into this.
Maybe having 2 function rather than a bool in the API that end up being a uint8_t ?
The doc should specify if it finalize or not when disposing.
DWOId yields notthing relevant on Google. Maybe this needs to be explained a bit more.
It hasn't been enforced consistently int he past, so that may not be immediately obvious, but we usually pass a pointer and a length for string in the newer API. This avoid useless calls to strlen and works even if the string isn't zero terminated which is a plus. Keep in mind that the C API is often used to bind to other languages, so while this may not be the most idiomatic thing to do in C, this ends up fitting our use case better.
There is a facility to unwrap subclasses. You can see LLVMValueRef for how it is done. You shouldn't need to write this.
Hey cool that you are doing this work, finally!
See inline comments (also click the done tag on the comments when those are fixed, please).
Regarding the tests, only since this API is only about creating debug info I'm okay with just a creation test, this API already have a special status.
Please use size_t for the the string sizes, no need to go to 64bit on 32bit systems.
This is looking good and I like where this is going. I have a few nits in comments.
Where I'm more doubtful is for the test. The way we've tested the C API in the past is by reading a module and then re-emiting a clone of it on the output. This patch doesn't have the ability to read debug infos, so that's a bit compromised. One way forward is obviously to add reading support for the elements we add emission support from. I'm not sure how much work that would be, so I'm not sure how practical this is within the scope of that diff. If that's too hard then an alternative should be chosen, like emitting a given module and checking its output. This is where this patch is going, however, it doesn't looks like this patch actually checks the output so that's a problem.
These id needs to persist across versions, and this is not ensuring this. You can look at other enums in Core.h to see how it is done. The basic idea is to list all the enum values here, and then use the macro option to generate the mapping between exposed values and internal llvm values.
Please use LLVMBool
LLVMBool for flags.