[lldb] Refactor command option enum values (NFC)

Refactor the command option enum values and the command argument table
to 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 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

show more ...

[lldb] Make the g_arguments_data constexpr and fix the static assert

This fixes the static assert that's meant to keep the g_arguments_data
table in sync with the CommandArgumentType enumeration. In

[lldb] Make the g_arguments_data constexpr and fix the static assert

This fixes the static assert that's meant to keep the g_arguments_data
table in sync with the CommandArgumentType enumeration. Indeed, the
assert didn't fire even though the current code is missing an entry.
This patches fixes that as well.

Differential revision: https://reviews.llvm.org/D129529

show more ...

Refine error msgs from CommandObject & Disassemble

Make it clearer for end users why a command cannot be used
when a process is not stopped, etc.

Differential Revision: https://reviews.llvm.org/D12

Refine error msgs from CommandObject & Disassemble

Make it clearer for end users why a command cannot be used
when a process is not stopped, etc.

Differential Revision: https://reviews.llvm.org/D120594

show more ...

Add a repeat command option for "thread backtrace --count N".

This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the

Add a repeat command option for "thread backtrace --count N".

This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the stack.

This took a little more effort than just adding the repeat command, since
the GetRepeatCommand API was returning a "const char *". That meant the command
had to keep the repeat string alive, which is inconvenient. The original
API returned either a nullptr, or a const char *, so I changed the private API to
return an llvm::Optional<std::string>. Most of the patch is propagating that change.

Also, there was a little thinko in fetching the repeat command. We don't
fetch repeat commands for commands that aren't being added to history, which
is in general reasonable. And we don't add repeat commands to the history -
also reasonable. But we do want the repeat command to be able to generate
the NEXT repeat command. So I adjusted the logic in HandleCommand to work
that way.

Differential Revision: https://reviews.llvm.org/D119046

show more ...

[lldb] Remove unused AproposAllSubCommands (NFC)

Add a "command container" hierarchy to allow users to add container nodes.

The point is to allow users with a related set of script based commands
to organize their commands in a hierarchy in the co

Add a "command container" hierarchy to allow users to add container nodes.

The point is to allow users with a related set of script based commands
to organize their commands in a hierarchy in the command set, rather than
having to have only top-level commands.

Differential Revision: https://reviews.llvm.org/D110298

show more ...

[lldb/Interpreter][NFC] Replace default constructors/destructors bodies with "=default"

[lldb] Add missing member initialziation list

My previous commit added the default arguments but didn't use them in
the member initialization list...

[lldb] Change the CommandArgumentData ctor (NFC)

By using default arguments the caller can specify a subset without the
need for overloads. This is particularly useful in combination with
emplace_ba

[lldb] Change the CommandArgumentData ctor (NFC)

By using default arguments the caller can specify a subset without the
need for overloads. This is particularly useful in combination with
emplace_back as these objects are generally stored in a vector.

show more ...

[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 very
consistent 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 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

show more ...

Make llvm::StringRef to std::string conversions explicit.

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 m

Make llvm::StringRef to std::string conversions explicit.

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.

show more ...

[LLDB] Fix more -Wdocumentation issues (NFC)

[LLDB] Fix a bunch of -Wdocumentation warnings

[lldb] Unify target checking in CommandObject

Summary:
We currently have several CommandObjects that manually reimplement the checking for a selected target
or a target in the execution context (whi

[lldb] Unify target checking in CommandObject

Summary:
We currently have several CommandObjects that manually reimplement the checking for a selected target
or a target in the execution context (which is the selected target when they are invoked). This patch removes
all these checks and replaces them by setting the eCommandRequiresTarget flag that Pavel suggested. With
this flag we are doing the same check but without having to duplicate this code in all these CommandObjects.

I also added a `GetSelectedTarget()` variant of the `GetSelectedOrDummyTarget()` function to the
CommandObject that checks that the flag is set and then returns a reference to the target. I didn't rewrite
all the `target` variables from `Target *` to `Target &` in this patch as last time this change caused a lot of merge
conflicts in Swift and I would prefer having that in a separate NFC commit.

Reviewers: labath, clayborg

Reviewed By: labath, clayborg

Subscribers: clayborg, JDevlieghere, jingham, amccarth, abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D66863

llvm-svn: 370571

show more ...

[lldb][NFC] Update documentation of Handle[Argument]Completion

We no longer have return values or any of the mentioned arguments
in these functions since the introduction of CompletionRequest.

llvm

[lldb][NFC] Update documentation of Handle[Argument]Completion

We no longer have return values or any of the mentioned arguments
in these functions since the introduction of CompletionRequest.

llvm-svn: 370174

show more ...

[lldb][NFC] Remove dead code that handles situations where LLDB has no dummy target

Summary:
We always have a dummy target, so any error handling regarding a missing dummy target is dead code now.
A

[lldb][NFC] Remove dead code that handles situations where LLDB has no dummy target

Summary:
We always have a dummy target, so any error handling regarding a missing dummy target is dead code now.
Also makes the CommandObject methods that return Target& to express this fact in the API.

This patch just for the CommandObject part of LLDB. I'll migrate the rest of LLDB in a follow-up patch that's WIP.

Reviewers: labath

Reviewed By: labath

Subscribers: abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D66737

llvm-svn: 369939

show more ...

[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values

Summary:
We still have some leftovers of the old completion API in the inte

[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values

Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:

* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.

I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.

A few words why those things should be removed/replaced:

* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.

Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).

* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).

* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).

This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.

For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).

I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: arphaman, abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D66536

llvm-svn: 369624

show more ...

[ScriptInterpreter] Move ownership into debugger (NFC)

This is part two of the change started in r359330. This patch moves the
ownership of the script interpreter from the command interpreter into
t

[ScriptInterpreter] Move ownership into debugger (NFC)

This is part two of the change started in r359330. This patch moves the
ownership of the script interpreter from the command interpreter into
the debugger. I would've preferred to remove the lazy initialization,
however the fact that the scripting language is set after the debugger
is created makes that tricky. So for now this does exactly the same
thing as when it was under the command interpreter. The result is that
this patch is fully NFC.

Differential revision: https://reviews.llvm.org/D61211

llvm-svn: 359354

show more ...

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

Differential revision: https://reviews.llvm.org/D60508

llvm-svn: 358135

show more ...

Bring Doxygen comment syntax in sync with LLVM coding style.
This changes '@' prefix to '\'.

llvm-svn: 355841

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Remove header grouping comments.

This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdate

Remove header grouping comments.

This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.

llvm-svn: 346626

show more ...

Add support for descriptions with command completions.

Summary:
This patch adds a framework for adding descriptions to the command completions we provide.
It also adds descriptions for completed top

Add support for descriptions with command completions.

Summary:
This patch adds a framework for adding descriptions to the command completions we provide.
It also adds descriptions for completed top-level commands so that we can test this code.

Completions are in general supposed to be displayed alongside the completion itself. The descriptions
can be used to provide additional information about the completion to the user. Examples for descriptions
are function signatures when completing function calls in the expression command or the binary name
when providing completion for a symbol.

There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective
APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be
used), so that's why I still had to change some function signatures. Also, as the old API only passes around a
list of matches, and the descriptions are for these functions just another list, I had to add some code that
essentially just ensures that both lists are always the same side (e.g. all the manual calls to
`descriptions->AddString(X)` below a `matches->AddString(Y)` call).

The initial command descriptions that come with this patch are just reusing the existing
short help that is already added in LLDB.

An example completion with descriptions looks like this:
```
(lldb) pl
Available completions:
platform -- Commands to manage and create platforms.
plugin -- Commands for managing LLDB plugins.
```

Reviewers: #lldb, jingham

Reviewed By: #lldb, jingham

Subscribers: jingham, JDevlieghere, lldb-commits

Differential Revision: https://reviews.llvm.org/D51175

llvm-svn: 342181

show more ...

Add includes for CompletionRequest to every file that uses it

Summary: Should fix the builds (and prevent future builds from failing when people try to reduce includes).

Reviewers: jingham

Reviewe

Add includes for CompletionRequest to every file that uses it

Summary: Should fix the builds (and prevent future builds from failing when people try to reduce includes).

Reviewers: jingham

Reviewed By: jingham

Subscribers: jingham, lldb-commits

Differential Revision: https://reviews.llvm.org/D49311

llvm-svn: 337032

show more ...

Get rid of the C-string parameter in DoExecute

Summary:
This patch gets rid of the C-string parameter in the RawCommandObject::DoExecute function,
making the code simpler and less memory unsafe.

Th

Get rid of the C-string parameter in DoExecute

Summary:
This patch gets rid of the C-string parameter in the RawCommandObject::DoExecute function,
making the code simpler and less memory unsafe.

There seems to be a assumption in some command objects that this parameter could be a nullptr,
but from what I can see the rest of the API doesn't actually allow this (and other command
objects and related code pieces dereference this parameter without any checks).

Especially CommandObjectRegexCommand has error handling code for a nullptr that is now gone.

Reviewers: davide, jingham, teemperor

Reviewed By: teemperor

Subscribers: jingham, lldb-commits

Differential Revision: https://reviews.llvm.org/D49207

llvm-svn: 336955

show more ...