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

[via llvm-commits]

deadalnix wrote:

> and having constants that don't match the DWARF spec or LLVM's internal representation seems like it produces unnecessary complexity/divergence/etc

We usually try to avoid exposing constant that map to LLVM internal representation in the C API, because they are subject to change from one version to the next, and that's hard to deal with from a foreign language. This technique is used quite a bit in the `Core.h` module of the C API.

However, it does not seems worth using in the case of values defined in DWARF as they are not going to change.

> I guess the alternative would be to sink the Dwarf.def file down into the C API, use it there to generate the C enums.

This is what we do to generate - or not - method relative to different backends that may or may not have been built in a specific LLVM build. This is a bit of a pain to deal with.

> I don't quite understand the complaint about FFIs, though?

A very large number of language out there have a syntax to simply declare C functions and call them directly. Typically, people do not use the `.h` headers at all, but simply redeclare them in their target language and everything is linked together. An example of that is the [ocaml bindings](https://github.com/llvm/llvm-project/blob/2a2fd48/llvm/bindings/ocaml/debuginfo/llvm_debuginfo.mli) that are in the llvm tree, but there are numerous others out there.

The main drawback of that approach is that mismatch in declaration between the two end up linking together just fine and then corruption happens at runtime. This is why we impose on ourtselves tighter constraints when dealing with the C API, for instance, we do not shuffle enums values from one version to the next, or not adding/removing/reordering function parameters. This leads to the creation of functions such `LLVMBuildLoad2` instead of changing `LLVMBuildLoad`'s API when LLVM moved to `ptr`.

Right now, the use of def files in there is limited to `llvm/Config/Targets.def` and other similar files that define build options, so this is more or less unavoidable, but even then many simply decide that you must use a build that supports target X or Y, and the file are trivial to "parse" with a regex if need be.

Outside of this, the use of the preprocessor in the C API is exceedingly limited: include guards, include of standard library headers such as `stddef.h` and the C API module that needs each other include each others. That's pretty much it.

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