[lldb] Refactor command option enum values (NFC)Refactor the command option enum values and the command argument tableto connect the two. This has two benefits: - We guarantee that two options t
[lldb] Refactor command option enum values (NFC)Refactor the command option enum values and the command argument tableto connect the two. This has two benefits: - We guarantee that two options that use the same argument type have the same accepted values. - We can print the enum values and their description in the help output. (D129707)Differential revision: https://reviews.llvm.org/D129703
show more ...
[lldb]/Tablegen] Use ElementType instead of DefaultValueUnsingedThe fourth field in the property struct is the default unsigned or enumvalue for all types, except for Array and Dictionary types. F
[lldb]/Tablegen] Use ElementType instead of DefaultValueUnsingedThe fourth field in the property struct is the default unsigned or enumvalue for all types, except for Array and Dictionary types. For those,it is the element type. During the tablegen conversion, this wasincorrectly translated to DefaultValueUnsigned with a valuecorresponding to the OptionValue: enum type. So forOptionValue::eTypeString this became DefaultUnsignedValue<16>. Thispatch extends the tablegen backend to understand ElementType to expressthis as ElementType<"String">.Differential revision: https://reviews.llvm.org/D76535
[lldb] Update header guards to be consistent and compliant with LLVM (NFC)LLDB has a few different styles of header guards and they're not veryconsistent because things get moved around or copy/pa
[lldb] Update header guards to be consistent and compliant with LLVM (NFC)LLDB has a few different styles of header guards and they're not veryconsistent because things get moved around or copy/pasted. This patchunifies the header guards across LLDB and converts everything to matchLLVM's style.Differential revision: https://reviews.llvm.org/D74743
Make llvm::StringRef to std::string conversions explicit.This is how it should've been and brings it more in line withstd::string_view. There should be no functional change here.This is mostly m
Make llvm::StringRef to std::string conversions explicit.This is how it should've been and brings it more in line withstd::string_view. There should be no functional change here.This is mostly mechanical from a custom clang-tidy check, with a lot ofmanual fixups. It uncovers a lot of minor inefficiencies.This doesn't actually modify StringRef yet, I'll do that in a follow-up.
[lldb] Respect previously set values of LLDB_TABLEGEN_EXEIf you set LLDB_TABLEGEN_EXE in a CMake cache file or in the CMakeinvocation line, your setting isn't respected. Setting up the tablegenfo
[lldb] Respect previously set values of LLDB_TABLEGEN_EXEIf you set LLDB_TABLEGEN_EXE in a CMake cache file or in the CMakeinvocation line, your setting isn't respected. Setting up the tablegenfor the host will overwrite the value that we set LLDB_TABLEGEN_EXE to,which defeats the whole point of setting it in the first place.
[LLDB] Fix inline variable only used in assertion. (NFC)This prevents unused variable warning/error in -DNDEBUG builds. Thevariable was introduced in 5934cd11ea3e.Patch by: Shu-Chun WengDiffer
[LLDB] Fix inline variable only used in assertion. (NFC)This prevents unused variable warning/error in -DNDEBUG builds. Thevariable was introduced in 5934cd11ea3e.Patch by: Shu-Chun WengDifferential revision: https://reviews.llvm.org/D69451
[TableGen] Add asserts to make sure default values match property typeThis adds a few asserts to the property TableGen backend to preventmismatches between property types and their default values.
[TableGen] Add asserts to make sure default values match property typeThis adds a few asserts to the property TableGen backend to preventmismatches between property types and their default values. Thiswould've prevented a copy-paste mistake we discovered downstream.
[TableGen] Move helpers into LLDBTableGenUtils.Instead of polluting the LLDBTableGenBackends header with helpers usedby both emitters, move them into a separate files.llvm-svn: 367377
[TableGen] Include vectorFixes "no member named 'vector' in namespace 'std'" compile error.llvm-svn: 367375
[TableGen] Reuse typedef across emitters (NFC)This moves the std::map typedef into the header so it can be reused byall the emitter implementations.llvm-svn: 367363
[lldb] Also include the array definition in Properties.incRight now our Properties.inc only generates the initializer for theoptions list but not the array declaration boilerplate around it. As th
[lldb] Also include the array definition in Properties.incRight now our Properties.inc only generates the initializer for theoptions list but not the array declaration boilerplate around it. As thearray definition is identical for all arrays, we might as well also letthe Properties.inc generate it alongside the initializers.Unfortunately we cannot do the same for enums, as there's this magicePropertyExperimental, which needs to come at the end to be interpretedcorrectly. Hopefully we can get rid of this in the future and do thesame for the property enums.Differential revision: https://reviews.llvm.org/D65353llvm-svn: 367238
[lldb][NFC] Split emitting and parsing in LLDBOptionDefEmitterSplitting the different logic is cleaner and we it will be easierto implement the enum emitting (which otherwise would have toreimple
[lldb][NFC] Split emitting and parsing in LLDBOptionDefEmitterSplitting the different logic is cleaner and we it will be easierto implement the enum emitting (which otherwise would have toreimplement the Record parsing).llvm-svn: 367207
[lldb] Also include the array definition in CommandOptions.incSummary:Right now our CommandOptions.inc only generates the initializer for the options list butnot the array declaration boilerplate
[lldb] Also include the array definition in CommandOptions.incSummary:Right now our CommandOptions.inc only generates the initializer for the options list butnot the array declaration boilerplate around it. As the array definition is identical for all arrays,we might as well also let the CommandOptions.inc generate it alongside the initializers.This patch will also allow us to generate additional declarations related to that option list inthe future (e.g. a enum class representing the specific options which would make ourhandling code less prone).This patch also fixes a few option tables that didn't follow our naming style.Reviewers: JDevlieghereReviewed By: JDevlieghereSubscribers: abidh, lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D65331llvm-svn: 367186
[lldb] Don't dynamically allocate the posix option validator.We dynamically allocate the option validator which means wecan't mark this list of OptionDefinitions as constexpr. It's alsomore compl
[lldb] Don't dynamically allocate the posix option validator.We dynamically allocate the option validator which means wecan't mark this list of OptionDefinitions as constexpr. It's alsomore complicated than necessary.llvm-svn: 367102
[Tablegen] Fix issues caused by incorrect escaping.The printEscapedString would escape newlines by their ASCII valuesinstead of prefixing them with a `\`. Remove the escaping logic andescape the
[Tablegen] Fix issues caused by incorrect escaping.The printEscapedString would escape newlines by their ASCII valuesinstead of prefixing them with a `\`. Remove the escaping logic andescape the strings in the definition file.llvm-svn: 367065
Let tablegen generate property definitionsProperty definitions are currently defined in a PropertyDefinition arrayand have a corresponding enum to index in this array. Unfortunately thisis quite
Let tablegen generate property definitionsProperty definitions are currently defined in a PropertyDefinition arrayand have a corresponding enum to index in this array. Unfortunately thisis quite error prone. Indeed, just today we found an incorrect mergewhere a discrepancy between the order of the enum values and theirdefinition caused the test suite to fail spectacularly.Tablegen can streamline the process of generating the propertydefinition table while at the same time guaranteeing that the enums stayin sync. That's exactly what this patch does. It adds a new tablegenfile for the properties, building on top of the infrastructure thatRaphael added recently for the command options. It also introduces twonew tablegen backends: one for the property definitions and one fortheir corresponding enums.It might be worth mentioning that I generated most of the tablegendefinitions from the existing property definitions, by adding a dumpmethod to the struct. This seems both more efficient and less errorprone that copying everything over by hand. Only Enum properties neededmanual fixup for the EnumValues and DefaultEnumValue fields.Differential revision: https://reviews.llvm.org/D65185llvm-svn: 367058
[TableGen] Fix comments/headers referencing clang (NFC)Remove references to clang's TableGen implementation. Presumably thesefiles were originally copied over.llvm-svn: 366982
[lldb] Fix enum value descriptionllvm-svn: 366863
[Utils] Add back utils directoryDue to a bug my earlier commit removed the whole utils directory:https://reviews.llvm.org/D65123llvm-svn: 366830
[Utils] Remove legacy scriptsAs pointed out by Nathan in D65155, these scrips don't seem to serve anyreal need anymore.llvm-svn: 366827
[lldb][NFC] Tablegenify breakpointllvm-svn: 366673
[lldb] Don't double emit option groupsWe currently emit the option groups twice if Groups<[1,2,3]> isused in the tablegen. This leads to compilation errors. Thispatch just removes the line that a
[lldb] Don't double emit option groupsWe currently emit the option groups twice if Groups<[1,2,3]> isused in the tablegen. This leads to compilation errors. Thispatch just removes the line that accidentially emits the optiongroup a second time.llvm-svn: 366414
Only build lldb-tblgen if it's not a current targetSummary:When doing standalone builds, you could potentially be building againstan llvm which also built lldb. If this were the case, you'd beat
Only build lldb-tblgen if it's not a current targetSummary:When doing standalone builds, you could potentially be building againstan llvm which also built lldb. If this were the case, you'd beattempting to build this target twice.Reviewers: xiaobaiSubscribers: mgornyDifferential Revision: https://reviews.llvm.org/D64847llvm-svn: 366394
[lldb] Let table gen create command option initializers.Summary:We currently have man large arrays containing initializers for our command options.These tables are tricky maintain as we don't hav
[lldb] Let table gen create command option initializers.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 andit'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 readablesyntax for this (especially for all the default arguments) and we can let TableCheck check themfor 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 otheroption initializers tables in separate patches.Reviewers: JDevlieghere, davide, sgraenitzReviewed By: JDevlieghereSubscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D64365llvm-svn: 365908