Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly.
Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums.
It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields.
These unqualified #include directives are causing us some problems downstream. What do you think about qualifying these like other includes in the file? i.e. #include "Plugins/DynamicLoader/Darwin-Kernel/Properties.inc"
The problem is that these "local" includes can only resolve to the right thing if the build system specifies a different -I line to each relevant cpp file (or the header lives next to the source file, which isn't the case for generated files).
Many build systems (including both CMake and bazel) only support doing this for separate libraries, however lldb's source isn't sufficiently clearly layered to allow splitting into fine-grained libraries in bazel (CMake is much more lax here).
While CMake is the gold standard here, it'd be helpful to make it possible to build with other systems out-of-tree. @chandlerc was looking at this issue and has more context and opinions here.
It also seems a bit less magic and more consistent with the rest of the includes in the file, as well as with the project. (Most, though sadly not all, .inc files in llvm are included by qualified paths).
I'll send a patch shortly after verifying it fixes the issue.