[llvm] [C API] Add bindings for DWARF type encoding. (PR #102171)

[via llvm-commits]

deadalnix wrote:

I'm allowing myself to resurrect this.

I'm not sure how to convince you guys that this is the right path forward, but I remain convinced this is. I came back to this because of the release of LLVM 20 which lead me to have to update binding again and this patch is useful doing so.

It boils down to the way people typically do binding to other languages. Take the C header, translate declaration by declaration, and use the translation. Having the valus in there directly is easier in this case. let me run through the objections in the discussion:
1. Having the enum be generated from def files means on the the other side to have to write some code that parses the def file, and generate bindings from it, While unavoidable in some cases, for instance to know which target are compiled in or not, this significantly increase the difficulty of creating a binding. In this case, because the values don't change, this is making things harder for no good reasons.
2. Running the preprocessor first is not really a good option. You lose a lot of information about the source that you'd want to translate in another language. For instance, `#include` would be typically be translated in a module import in languages that support modules. This also creates humongous files that are impractical to translate by hand.
3. While I understand that duplicating the infos about DWARF values in there is unsatisfying, the other side of the coin is that they are not going to change, and if ever they were unmaintained, the worst that would happen is that the latest and greatest DWARF feature wouldn't be easily accessible through the C API. This isn't a big downside.

@jryans I'm going to try to expend a bit more on why the `.def` are not ideal. When you have a solid declaration in the C header, you can create a corresponding declaration in the binding for the other language and be done with it. When you have a `.def` , you end up having to parse it to generate declaration in whatever target language you have. You find yourself unable to use the preprocessor in similar way the C header do, because the target language typically do not have a preprocessor, which is very C specific. You also cannot just write the value in there, because you don't know if the LLVM on the user of the bindings does have the same `.def` as the one you are making the binding on. So you end up having to write a parser for the `.def` and have a complex build process that involve finding the `.def` on the user's machine and adjust the bindings accordingly.

This is not a blocker and definitively possible, but it is significantly harder than copy paste the C enum's into the binding and tweak the syntax to match the one of the target language.

In practice this translates to part of the API just not being added to bindings, or more insidious, part of the API being ported incorrectly.

https://github.com/llvm/llvm-project/pull/102171