summaryrefslogtreecommitdiff
path: root/lldb/utils/TableGen/LLDBTableGen.cpp
AgeCommit message (Collapse)Author
2024-09-09[LLDB][TableGen] Migrate lldb-tblgen to use const RecordKeeper (#107536)Rahul Joshi
Migrate LLDB TableGen backend to use const RecordKeeper. This is a part of effort to have better const correctness in TableGen backends: https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
2024-06-21[CommandLine] Avoid ManagedStatic.h include (NFC)Nikita Popov
The two variables using ManagedStatic that are exported by this header are not actually used anywhere -- they are used through SubCommand::getTopLevel() and SubCommand::getAll() instead. Drop the extern declarations and the include.
2024-05-01[lldb] Use Python script to generate SBLanguages.h (#90753)Jonas Devlieghere
Use a Python script to generate SBLanguages.h instead of piggybacking on LLDB TableGen. This addresses Nico Weber's post-commit feedback.
2024-04-29Add a new SBExpressionOptions::SetLanguage() API (NFCI) (#89981)Adrian Prantl
that separates out language and version. To avoid reinventing the wheel and introducing subtle incompatibilities, this API uses the table of languages and versiond defined by the upcoming DWARF 6 standard (https://dwarfstd.org/languages-v6.html). While the DWARF 6 spec is not finialized, the list of languages is broadly considered stable. The primary motivation for this is to allow the Swift language plugin to switch between language dialects between, e.g., Swift 5.9 and 6.0 with out introducing a ton of new language codes. On the main branch this change is considered NFC. Depends on https://github.com/llvm/llvm-project/pull/89980
2019-07-25Let tablegen generate property definitionsJonas Devlieghere
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. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-25[TableGen] Fix comments/headers referencing clang (NFC)Jonas Devlieghere
Remove references to clang's TableGen implementation. Presumably these files were originally copied over. llvm-svn: 366982
2019-07-23[lldb] Fix enum value descriptionJonas Devlieghere
llvm-svn: 366863
2019-07-23[Utils] Add back utils directoryJonas Devlieghere
Due to a bug my earlier commit removed the whole utils directory: https://reviews.llvm.org/D65123 llvm-svn: 366830
2019-07-23[Utils] Remove legacy scriptsJonas Devlieghere
As pointed out by Nathan in D65155, these scrips don't seem to serve any real need anymore. llvm-svn: 366827
2019-07-12[lldb] Let table gen create command option initializers.Raphael Isemann
Summary: We currently have man large arrays containing initializers for our command options. These tables are tricky maintain as we don't have any good place to check them for consistency and it's also hard to read (`nullptr, {}, 0` is not very descriptive). This patch fixes this by letting table gen generate those tables. This way we can have a more readable syntax for this (especially for all the default arguments) and we can let TableCheck check them for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.). Also refactoring the related data structures can now be done without changing the hundred of option initializers. For example, this line: ``` {LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."}, ``` becomes this: ``` def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">; ``` For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other option initializers tables in separate patches. Reviewers: JDevlieghere, davide, sgraenitz Reviewed By: JDevlieghere Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64365 llvm-svn: 365908