[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
ant

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

` ResultTy DoFoo(Status& error)
`
to

` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

show more ...

Start to clean up the process of defining command arguments. (#83097)

Partly, there's just a lot of unnecessary boiler plate. It's also
possible to define combinations of arguments that make no sen

Start to clean up the process of defining command arguments. (#83097)

Partly, there's just a lot of unnecessary boiler plate. It's also
possible to define combinations of arguments that make no sense (e.g.
eArgRepeatPlus followed by eArgRepeatPlain...) but these are never
checked since we just push_back directly into the argument definitions.

This commit is step 1 of this cleanup - do the obvious stuff. In it, all
the simple homogenous argument lists and the breakpoint/watchpoint
ID/Range types, are set with common functions. This is an NFC change, it
just centralizes boiler plate. There's no checking yet because you can't
get a single argument wrong.

The end goal is that all argument definition goes through functions and
m_arguments is hidden so that you can't define inconsistent argument
sets.

show more ...

Add the RegisterCompleter to eArgTypeRegisterName in g_argument_table (#82428)

This is a follow-on to:

https://github.com/llvm/llvm-project/pull/82085

The completer for register names was miss

Add the RegisterCompleter to eArgTypeRegisterName in g_argument_table (#82428)

This is a follow-on to:

https://github.com/llvm/llvm-project/pull/82085

The completer for register names was missing from the argument table. I
somehow missed that the only register completer test was x86_64, so that
test broke.

I added the completer in to the right slot in the argument table, and
added a small completions test that just uses the alias register names.
If we end up having a platform that doesn't define register names, we'll
have to skip this test there, but it should add a sniff test for
register completion that will run most everywhere.

show more ...

Revert "Centralize the handling of completion for simple argument lists. (#82085)"

This reverts commit 21631494b068d9364b8dc8f18e59adee9131a0a5.

Reverted because of greendragon failure:

**********

Revert "Centralize the handling of completion for simple argument lists. (#82085)"

This reverts commit 21631494b068d9364b8dc8f18e59adee9131a0a5.

Reverted because of greendragon failure:

******************** TEST 'lldb-api :: functionalities/completion/TestCompletion.py' FAILED ********************
Script:

show more ...

Centralize the handling of completion for simple argument lists. (#82085)

Most commands were adding argument completion handling by themselves,
resulting in a lot of unnecessary boilerplate. In man

Centralize the handling of completion for simple argument lists. (#82085)

Most commands were adding argument completion handling by themselves,
resulting in a lot of unnecessary boilerplate. In many cases, this could
be done generically given the argument definition and the entries in the
g_argument_table.

I'm going to address this in a couple passes. In this first pass, I
added handling of commands that have only one argument list, with one
argument type, either single or repeated, and changed all the commands
that are of this sort (and don't have other bits of business in their
completers.)

I also added some missing connections between arg types and completions
to the table, and added a RemoteFilename and RemotePath to use in places
where we were using the Remote completers. Those arguments used to say
they were "files" but they were in fact remote files.

I also added a module arg type to use where we were using the module
completer. In that case, we should call the argument module.

show more ...

[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` return `void` (not `bool`) (#69991)

[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` to return
`void` instead of ~~`bool`~

[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` return `void` (not `bool`) (#69991)

[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` to return
`void` instead of ~~`bool`~~

Justifications:
- The code doesn't ultimately apply the `true`/`false` return values.
- The methods already pass around a `CommandReturnObject`, typically
with a `result` parameter.
- Each command return object already contains:
- A more precise status
- The error code(s) that apply to that status

Part 1 refactors the `CommandObject::Execute(...)` method.
- See
[https://github.com/llvm/llvm-project/pull/69989](https://github.com/llvm/llvm-project/pull/69989)

rdar://117378957

show more ...

Reland "[LLDB] Fix the use of "platform process launch" with no extra arguments"

This reverts commit 3254623d73fb7252385817d8057640c9d5d5ffd1.

One test has been updated to add the "-s" flag which a

Reland "[LLDB] Fix the use of "platform process launch" with no extra arguments"

This reverts commit 3254623d73fb7252385817d8057640c9d5d5ffd1.

One test has been updated to add the "-s" flag which along with
86fd957af981f146a306831608d7ad2de65b9560 should fix the tests on MacOS.

An assert on hijack listener added in that patch was removed, it seems
to be correct on MacOS but not on Linux.

show more ...

[lldb] Duplicate Target::Launch resuming logic into CommandObjectPlatformProcessLaunch

Fix `platform process launch` on macOS where it fails for lack of auto-resuming support.

This change reproduce

[lldb] Duplicate Target::Launch resuming logic into CommandObjectPlatformProcessLaunch

Fix `platform process launch` on macOS where it fails for lack of auto-resuming support.

This change reproduces the resuming logic found in `Target::Launch`.

This issue was identified by @DavidSpickett in D153636. This change relies on the tests
added in that PR. Thanks David.

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

show more ...

Revert "[LLDB] Fix the use of "platform process launch" with no extra arguments"

This reverts commit cc0fc358540517a3d205243c27bd543afeae2b02 due to a failure
reported on MacOS.

[LLDB] Fix the use of "platform process launch" with no extra arguments

This fixes #62068.

After 8d1de7b34af46a089eb5433c700419ad9b2923ee the following issue appeared:
```
$ ./bin/lldb /tmp/test.o

[LLDB] Fix the use of "platform process launch" with no extra arguments

This fixes #62068.

After 8d1de7b34af46a089eb5433c700419ad9b2923ee the following issue appeared:
```
$ ./bin/lldb /tmp/test.o
(lldb) target create "/tmp/test.o"
Current executable set to '/tmp/test.o' (aarch64).
(lldb) platform process launch -s
error: Cannot launch '': Nothing to launch
```

Previously would call target->GetRunArguments when there were no extra
arguments, so we could find out what target.run-args might be.

Once that change started relying on the first arg being the exe,
the fact that that call clears the existing argument list caused the bug.

Instead, have it set a local arg list and append that to the existing
one. Which in this case will just contain the exe name.

Since there's no existing tests for this command I've added a new file
that covers enough to check this issue.

Reviewed By: labath

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

show more ...

[lldb/Commands] Add support to auto-completion for user commands

This patch should allow the user to set specific auto-completion type
for their custom commands.

To do so, we had to hoist the `Comp

[lldb/Commands] Add support to auto-completion for user commands

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>

show more ...

[lldb/Utility] Fix layering violation caused by ScriptedMetadata

This patch moves `ScriptedMetadata.h` from the `Interpreter` directory to
the `Utility` sub-directory since `ProcessInfo.h` depends o

[lldb/Utility] Fix layering violation caused by ScriptedMetadata

This patch moves `ScriptedMetadata.h` from the `Interpreter` directory to
the `Utility` sub-directory since `ProcessInfo.h` depends on it.

It also gets rid of the unused `OptionGroupPythonClassWithDict`
constructor for `ScriptedMetadata` which would address the layering
violation.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

show more ...

[lldb/Plugins] Add Attach capabilities to ScriptedProcess

This patch adds process attach capabilities to the ScriptedProcess
plugin. This doesn't really expects a PID or process name, since the
proc

[lldb/Plugins] Add Attach capabilities to ScriptedProcess

This patch adds process attach capabilities to the ScriptedProcess
plugin. This doesn't really expects a PID or process name, since the
process state is already script, however, this allows to create a
scripted process without requiring to have an executuble in the target.

In order to do so, this patch also turns the scripted process related
getters and setters from the `ProcessLaunchInfo` and
`ProcessAttachInfo` classes to a `ScriptedMetadata` instance and moves
it in the `ProcessInfo` class, so it can be accessed interchangeably.

This also adds the necessary SWIG wrappers to convert the internal
`Process{Attach,Launch}InfoSP` into a `SB{Attach,Launch}Info` to pass it
as argument the scripted process python implementation and convert it
back to the internal representation.

rdar://104577406

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

show more ...

[lldb] Add scripted process launch/attach option to {,platform }process commands

This patch does several things:

First, it refactors the `CommandObject{,Platform}ProcessObject` command
option class

[lldb] Add scripted process launch/attach option to {,platform }process commands

This patch does several things:

First, it refactors the `CommandObject{,Platform}ProcessObject` command
option class into a separate `CommandOptionsProcessAttach` option group.

This will make sure both the `platform process attach` and `process attach`
command options will always stay in sync without having with duplicate
them each time. But more importantly, making this class an `OptionGroup`
allows us to combine with a `OptionGroupPythonClassWithDict` to add
support for the scripted process managing class name and user-provided
dictionary options.

This patch also improves feature parity between `ProcessLaunchInfo` and
`ProcessAttachInfo` with regard to ScriptedProcesses, by exposing the
various getters and setters necessary to use them through the SBAPI.

This is foundation work for adding support to "attach" to a process from
the scripted platform.

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

show more ...

[LLDB] Fix help text for "platform settings"

This claims to take a platform name argument but doesn't.

That was probably the intent in fbb7634934d40548b650574a2f2a85ab41527674
but it has only ever

[LLDB] Fix help text for "platform settings"

This claims to take a platform name argument but doesn't.

That was probably the intent in fbb7634934d40548b650574a2f2a85ab41527674
but it has only ever worked with the current platform.

Reviewed By: clayborg

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

show more ...

Revert "[lldb] Add Debugger & ScriptedMetadata reference to Platform::CreateInstance"

This reverts commit 2d53527e9c64c70c24e1abba74fa0a8c8b3392b1.

[lldb] Add Debugger & ScriptedMetadata reference to Platform::CreateInstance

This patch is preparatory work for Scripted Platform support and does
multiple things:

First, it introduces new options

[lldb] Add Debugger & ScriptedMetadata reference to Platform::CreateInstance

This patch is preparatory work for Scripted Platform support and does
multiple things:

First, it introduces new options for the `platform select` command and
`SBPlatform::Create` API, to hold a reference to the debugger object,
the name of the python script managing the Scripted Platform and a
structured data dictionary that the user can use to pass arbitrary data.

Then, it updates the various `Create` and `GetOrCreate` methods for
the `Platform` and `PlatformList` classes to pass down the new parameter
to the `Platform::CreateInstance` callbacks.

Finally, it updates every callback to reflect these changes.

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

show more ...

Move from llvm::makeArrayRef to ArrayRef deduction guides - last part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

Differential Re

Move from llvm::makeArrayRef to ArrayRef deduction guides - last part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

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

show more ...

[NFC] Fix leak in command options configuration.

`m_options.Append(new OptionPermissions())` leaks because the pointer passed in is not owned. Use a class member to ensure lifetime, which is the com

[NFC] Fix leak in command options configuration.

`m_options.Append(new OptionPermissions())` leaks because the pointer passed in is not owned. Use a class member to ensure lifetime, which is the common pattern used for this API.

Found by the LLDB command interpreter fuzzer. The fuzz input is running `ap $` twice.

show more ...

[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 ...

Have CommandObjectParsed check for "commands that take no arguments".

This is currently being done in an ad hoc way, and so for some
commands it isn't being checked. We have the info to make this c

Have CommandObjectParsed check for "commands that take no arguments".

This is currently being done in an ad hoc way, and so for some
commands it isn't being checked. We have the info to make this check,
since commands are supposed to add their arguments to the m_arguments
field of the CommandObject. This change uses that info to check whether
the command received arguments in error.

A handful of commands weren't defining their argument types, I also had
to fix them. And a bunch of commands were checking for arguments by
hand, so I removed those checks in favor of the CommandObject one. That
also meant I had to change some tests that were checking for the ad hoc
error outputs.

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

show more ...

[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB

Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

Dif

[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB

Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

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

show more ...

[lldb/Platform] Prepare decouple instance and plugin names

This patch changes the return value of Platform::GetName() to a
StringRef, and uses the opportunity (compile errors) to change some
callsit

[lldb/Platform] Prepare decouple instance and plugin names

This patch changes the return value of Platform::GetName() to a
StringRef, and uses the opportunity (compile errors) to change some
callsites to use GetPluginName() instead. The two methods still remain
hardwired to return the same thing, but this will change once the ideas
in
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>
are implemented.

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

show more ...

[Commands] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

[lldb] Remove ConstString from Platform plugin names