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.
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode
(`set_property(TARGET <target> PROPERTY FOLDER "<title>")`)
when using the respective CMake's IDE generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
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
This patch should allow the user to set specific auto-completion type
for their custom commands.
To do so, we had to hoist the `CompletionType` enum so the user can
access it and add a new completion type flag to the CommandScriptAdd
Command Object.
So now, the user can specify which completion type will be used with
their custom command, when they register it.
This also makes the `crashlog` custom commands use disk-file completion
type, to browse through the user file system and load the report.
Differential Revision: https://reviews.llvm.org/D152011
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Refactor the command option enum values and the command argument table
to 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
The fourth field in the property struct is the default unsigned or enum
value for all types, except for Array and Dictionary types. For those,
it is the element type. During the tablegen conversion, this was
incorrectly translated to DefaultValueUnsigned with a value
corresponding to the OptionValue: enum type. So for
OptionValue::eTypeString this became DefaultUnsignedValue<16>. This
patch extends the tablegen backend to understand ElementType to express
this as ElementType<"String">.
Differential revision: https://reviews.llvm.org/D76535
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
If you set LLDB_TABLEGEN_EXE in a CMake cache file or in the CMake
invocation line, your setting isn't respected. Setting up the tablegen
for 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.
This prevents unused variable warning/error in -DNDEBUG builds. The
variable was introduced in 5934cd11ea3e.
Patch by: Shu-Chun Weng
Differential revision: https://reviews.llvm.org/D69451
This adds a few asserts to the property TableGen backend to prevent
mismatches between property types and their default values. This
would've prevented a copy-paste mistake we discovered downstream.
Right now our Properties.inc only generates the initializer for the
options list but not the array declaration boilerplate around it. As the
array definition is identical for all arrays, we might as well also let
the Properties.inc generate it alongside the initializers.
Unfortunately we cannot do the same for enums, as there's this magic
ePropertyExperimental, which needs to come at the end to be interpreted
correctly. Hopefully we can get rid of this in the future and do the
same for the property enums.
Differential revision: https://reviews.llvm.org/D65353
llvm-svn: 367238
Splitting the different logic is cleaner and we it will be easier
to implement the enum emitting (which otherwise would have to
reimplement the Record parsing).
llvm-svn: 367207
Summary:
Right now our CommandOptions.inc only generates the initializer for the options list but
not 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 in
the future (e.g. a enum class representing the specific options which would make our
handling code less prone).
This patch also fixes a few option tables that didn't follow our naming style.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65331
llvm-svn: 367186
We dynamically allocate the option validator which means we
can't mark this list of OptionDefinitions as constexpr. It's also
more complicated than necessary.
llvm-svn: 367102
The printEscapedString would escape newlines by their ASCII values
instead of prefixing them with a `\`. Remove the escaping logic and
escape the strings in the definition file.
llvm-svn: 367065
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
We currently emit the option groups twice if Groups<[1,2,3]> is
used in the tablegen. This leads to compilation errors. This
patch just removes the line that accidentially emits the option
group a second time.
llvm-svn: 366414
Summary:
When doing standalone builds, you could potentially be building against
an llvm which also built lldb. If this were the case, you'd be
attempting to build this target twice.
Reviewers: xiaobai
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D64847
llvm-svn: 366394
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
