Fix the sort function for languages to have "strict weak ordering". (#114160)

If you build libstdc++ with "debug" strictness, the test
TestTypeLookup.py will assert. That's because we're calling ll

Fix the sort function for languages to have "strict weak ordering". (#114160)

If you build libstdc++ with "debug" strictness, the test
TestTypeLookup.py will assert. That's because we're calling llvm::sort
(which redirects to std::sort) with a function that doesn't obey strict
weak ordering.

The error was that when the two languages were equal, we're sometimes
returning `true` but strict weak ordering requires that always be false.

This patch just makes the function behave properly.

show more ...

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

Add a new SBExpressionOptions::SetLanguage() API (NFCI) (#89981)

that separates out language and version. To avoid reinventing the wheel
and introducing subtle incompatibilities, this API uses the

Add a new SBExpressionOptions::SetLanguage() API (NFCI) (#89981)

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

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] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,end

[lldb] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

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

[lldb] Allow synthetic providers in C++ and fix linking problems

- Allow the definition of synthetic formatters in C++ even when LLDB is built without python scripting support.
- Fix linking problem

[lldb] Allow synthetic providers in C++ and fix linking problems

- Allow the definition of synthetic formatters in C++ even when LLDB is built without python scripting support.
- Fix linking problems with the CXXSyntheticChildren

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

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] Fix warning: extra ';' outside of a function is incompatible with C++98

Fix warning, remove trailing whitespace and fix formatting.

Improve the help output for `type XXX delete` where XXX is summary, format,
etc...

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

Make sure SelectMostRelevantFrame happens only when returning to the user.

This is a user facing action, it is meant to focus the user's attention on
something other than the 0th frame when you stop

Make sure SelectMostRelevantFrame happens only when returning to the user.

This is a user facing action, it is meant to focus the user's attention on
something other than the 0th frame when you stop somewhere where that's
helpful. For instance, stopping in pthread_kill after an assert will select
the assert frame.

This is not something you want to have happen internally in lldb, both
because internally you really don't want the selected frame changing out
from under you, and because the recognizers can do arbitrary work, and that
can cause deadlocks or other unexpected behavior.

However, it's not something that the current code does
explicitly after a stop has been delivered, it's expected to happen implicitly
as part of stopping. I changing this to call SMRF explicitly after a user
stop, but that got pretty ugly quickly.

So I added a bool to control whether to run this and audited all the current
uses to determine whether we're returning to the user or not.

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

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

[lldb] Make callback-based formatter matching available from the CLI.

This change adds a `--recognizer-function` (`-R`) to `type summary add`
and `type synth add` that allows users to specify that t

[lldb] Make callback-based formatter matching available from the CLI.

This change adds a `--recognizer-function` (`-R`) to `type summary add`
and `type synth add` that allows users to specify that the names in
the command are not type names but python function names.

It also adds an example to lldb/examples, and a section in the data
formatters documentation on how to use recognizer functions.

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

show more ...

[lldb] Add matching based on Python callbacks for data formatters.

This patch adds a new matching method for data formatters, in addition
to the existing exact typename and regex-based matching. The

[lldb] Add matching based on Python callbacks for data formatters.

This patch adds a new matching method for data formatters, in addition
to the existing exact typename and regex-based matching. The new method
allows users to specify the name of a Python callback function that
takes a `SBType` object and decides whether the type is a match or not.

Here is an overview of the changes performed:

- Add a new `eFormatterMatchCallback` matching type, and logic to handle
it in `TypeMatcher` and `SBTypeNameSpecifier`.

- Extend `FormattersMatchCandidate` instances with a pointer to the
current `ScriptInterpreter` and the `TypeImpl` corresponding to the
candidate type, so we can run registered callbacks and pass the type
to them. All matcher search functions now receive a
`FormattersMatchCandidate` instead of a type name.

- Add some glue code to ScriptInterpreterPython and the SWIG bindings to
allow calling a formatter matching callback. Most of this code is
modeled after the equivalent code for watchpoint callback functions.

- Add an API test for the new callback-based matching feature.

For more context, please check the RFC thread where this feature was
originally discussed:
https://discourse.llvm.org/t/rfc-python-callback-for-data-formatters-type-matching/64204/11

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

show more ...

[NFCI] More TypeCategoryImpl refactoring.

The main aim of this patch is to delete the remaining instances of code
reaching into the internals of `TypeCategoryImpl`. I made the following
changes:

-

[NFCI] More TypeCategoryImpl refactoring.

The main aim of this patch is to delete the remaining instances of code
reaching into the internals of `TypeCategoryImpl`. I made the following
changes:

- Add some more methods to `TieredFormatterContainer` and
`TypeCategoryImpl` to expose functionality that is implemented in
`FormattersContainer`.

- Add new overloads of `TypeCategoryImpl::AddTypeXXX` to make it easier
to add formatters to categories without reaching into the internal
`FormattersContainer` objects.

- Remove the `GetTypeXXXContainer` and `GetRegexTypeXXXContainer`
accessors from `TypeCategoryImpl` and update all call sites to use the
new methods instead.

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

show more ...

[lldb] Skip check for conflicting filter/synth when adding a new regex.

When adding a new synthetic child provider, we check for an existing
conflicting filter in the same category (and vice versa).

[lldb] Skip check for conflicting filter/synth when adding a new regex.

When adding a new synthetic child provider, we check for an existing
conflicting filter in the same category (and vice versa). This is done
by trying to match the new type name against registered formatters.

However, the new type name we're registered can also be a regex
(`type synth add -x`), and in this case the conflict check is just
wrong: it will try to match the new regex as if it was a type name,
against previously registered regexes.

See https://github.com/llvm/llvm-project/issues/57947 for a longer
explanation with concrete examples of incorrect behavior.

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

show more ...

[NFCI] Simplify TypeCategoryImpl for-each callbacks.

The callback system to iterate over every formatter of a given kind in
a TypeCategoryImpl is only used in one place (the implementation of
`type

[NFCI] Simplify TypeCategoryImpl for-each callbacks.

The callback system to iterate over every formatter of a given kind in
a TypeCategoryImpl is only used in one place (the implementation of
`type {formatter_kind} list`), and it's too convoluted for the sake of
unused flexibility.

This change changes it so that only one callback is passed to `ForEach`
(instead of a callback for exact matches and another one for regex
matches), and moves the iteration logic to `TieredFormatterContainer`
to avoid duplication.

If in the future we need different logic in the callback depending on
exact/regex match, the callback can get the type of formatter matching
used from the TypeMatcher argument anyway.

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

show more ...

[NFCI] Clean up enum FormatCategoryItem.

- Merge pairs like `eFormatCategoryItemSummary` and
`eFormatCategoryItemRegexSummary` into a single value. See explanation
below.

- Rename `eFormatCateg

[NFCI] Clean up enum FormatCategoryItem.

- Merge pairs like `eFormatCategoryItemSummary` and
`eFormatCategoryItemRegexSummary` into a single value. See explanation
below.

- Rename `eFormatCategoryItemValue` to `eFormatCategoryItemFormat`. This
makes the enum match the names used elsewhere for formatter kinds
(format, summary, filter, synth).

- Delete unused values `eFormatCategoryItemValidator` and
`eFormatCategoryItemRegexValidator`.

This enum is only used to reuse some code in CommandObjectType.cpp. For
example, instead of having separate implementations for `type summary
delete`, `type format delete`, and so on, there's a single generic
implementation that takes an enum value, and then the specific commands
derive from it and set the right flags for the specific kind of
formatter.

Even though the enum distinguishes between regular and regex matches for
every kind of formatter, this distinction is never used: enum values are
always specified in pairs like
`eFormatCategoryItemSummary | eFormatCategoryItemRegexSummary`.

This causes some ugly code duplication in TypeCategory.cpp. In order to
handle every flag combination some code appears 8 times:

{format, summary, synth, filter} x {exact, regex}

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

show more ...

[lldb][NFCI] Refactor regex filtering logic in CommandObjectTypeFormatterList

Extract a bit of copy/pasted regex filtering logic into a separate
function and simplify it a little bit.

Differential

[lldb][NFCI] Refactor regex filtering logic in CommandObjectTypeFormatterList

Extract a bit of copy/pasted regex filtering logic into a separate
function and simplify it a little bit.

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

show more ...

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com:

1094796 1095721 1095728 1095737 1095741
1095756 1095779 1095789 1095805 1214552
1229457 1232475 1274006 1274010 1293427
1364800 1364802 1364804 1364812 1364816
1374902 1374909 1384975 1399312 1420451
1431704 1454230 1454554 1454615 1454579
1454594 1454832 1457759 1458696 1461909
1467658 1487814 1487830 1487845

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

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