[lldb/ClangExpressionParser] Fix compiler error due to `clang::CreateLLVMCodeGen()` API change

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
inf

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.

show more ...

[lldb] Convert "LLDB" log channel to the new API

[CodeCompletion] Signature help for braced constructor calls

Implementation is based on the "expected type" as used for
designated-initializers in braced init lists. This means it can deduce the typ

[CodeCompletion] Signature help for braced constructor calls

Implementation is based on the "expected type" as used for
designated-initializers in braced init lists. This means it can deduce the type
in some cases where it's not written:

void foo(Widget);
foo({ /*help here*/ });

Only basic constructor calls are in scope of this patch, excluded are:
- aggregate initialization (no help is offered for aggregates)
- initializer_list initialization (no help is offered for these constructors)

Fixes https://github.com/clangd/clangd/issues/306

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

show more ...

Use StringRef::contains (NFC)

[lldb] [gdb-remote] Add eOpenOptionReadWrite for future gdb compat

Modify OpenOptions enum to open the future path into synchronizing
vFile:open bits with GDB. Currently, LLDB and GDB use different

[lldb] [gdb-remote] Add eOpenOptionReadWrite for future gdb compat

Modify OpenOptions enum to open the future path into synchronizing
vFile:open bits with GDB. Currently, LLDB and GDB use different flag
models effectively making it impossible to match bits. Notably, LLDB
uses two bits to indicate read and write status, and uses union of both
for read/write. GDB uses a value of 0 for read-only, 1 for write-only
and 2 for read/write.

In order to future-proof the code for the GDB variant:

1. Add a distinct eOpenOptionReadWrite constant to be used instead
of (eOpenOptionRead | eOpenOptionWrite) when R/W access is required.

2. Rename eOpenOptionRead and eOpenOptionWrite to eOpenOptionReadOnly
and eOpenOptionWriteOnly respectively, to make it clear that they
do not mean to be combined and require update to all call sites.

3. Use the intersection of all three flags when matching against
the three possible values.

This commit does not change the actual bits used by LLDB.

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

show more ...

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

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

show more ...

[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.o

[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options

Reviewed By: aaron.ballman

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

show more ...

Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options"

This reverts commit 2dbe1c675fe94eeb7973dcc25b049d25f4ca4fa0.
Mo

Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options"

This reverts commit 2dbe1c675fe94eeb7973dcc25b049d25f4ca4fa0.
More buildbot failures

show more ...

[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.o

[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options

Reviewed By: aaron.ballman

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

show more ...

[lldb] Move ClangModulesDeclVendor ownership to ClangPersistentVariables from Target

More decoupling of plugins and non-plugins. Target doesn't need to
manage ClangModulesDeclVendor and ClangPersist

[lldb] Move ClangModulesDeclVendor ownership to ClangPersistentVariables from Target

More decoupling of plugins and non-plugins. Target doesn't need to
manage ClangModulesDeclVendor and ClangPersistentVariables is always available
in situations where you need ClangModulesDeclVendor.

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

show more ...

[lldb] Fix DataLayout reference after 0f1137ba79c0

[lldb] Don't emit a warning when using Objective-C getters in expressions

Clang emits a warning when accessing an Objective-C getter but not using the result.
This gets triggered when just trying to

[lldb] Don't emit a warning when using Objective-C getters in expressions

Clang emits a warning when accessing an Objective-C getter but not using the result.
This gets triggered when just trying to print a getter value in the expression parser (where
Clang just sees a normal expression like `obj.getter` while parsing).

This patch just disables the warning in the expression parser (similar to what we do with
the C++ equivalent of just accessing a member variable but not doing anything with it).

Reviewed By: kastiglione

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

show more ...

ExpressionParser: Migrate to FileEntryRef in ParseInternal, NFC

Migrate to the `FileEntryRef` overload of `SourceManager::createFileID`
(using `FileManager::getOptionalFileRef`) in
`ClangExpressionP

ExpressionParser: Migrate to FileEntryRef in ParseInternal, NFC

Migrate to the `FileEntryRef` overload of `SourceManager::createFileID`
(using `FileManager::getOptionalFileRef`) in
`ClangExpressionParser::ParseInternal`.

No functionality change here.

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

show more ...

[lldb][NFC] Refactor setup code for Clang diagnostics

[lldb] Add support for using variables with C++ keywords names in non-C++ expressions

LLDB is currently always activating C++ when parsing expressions as LLDB itself
is using C++ features when creat

[lldb] Add support for using variables with C++ keywords names in non-C++ expressions

LLDB is currently always activating C++ when parsing expressions as LLDB itself
is using C++ features when creating the final AST that will be codegen'd
(specifically, references to variables, namespaces and using declarations are
used).

This is causing problems for users that have variables in non-C++ programs (e.g.
plain C or Objective-C) that have names which are keywords in C++. Expressions
referencing those variables fail to parse as LLDB's Clang parser thinks those
identifiers are C++ keywords and not identifiers that may belong to a
declaration.

We can't just disable C++ in the expression parser for those situations as
replacing the functionality of the injected C++ code isn't trivial. So this
patch is just disabling most keywords that are exclusive to C++ in LLDB's Clang
parser when we are in a non-C++ expression. There are a few keywords we can't
disable for now:

* `using` as that's currently used in some situations to inject variables into the expression function.
* `__null` as that's used by LLDB to define `NULL`/`Nil`/`nil`.

Getting rid of these last two keywords is possible but is a large enough change
that this will be handled in follow up patches.

Note that this only changes the keyword status of those tokens but this patch
does not remove any C++ functionality from the expression parser. The type
system still follows C++ rules and so does the rest of the expression parser.

There is another small change that gives the hardcoded macro definitions in LLDB
a higher precedence than the macros imported from the Objective-C modules. The
reason for this is that the Objective-C modules in LLDB are actually parsed in
Objective-C++ mode and they end up providing the C++ definitions of certain
system macros (like `NULL` being defined as `nullptr`). So we have to move the
LLDB definition forward and surround the definition from the module with an
`#ifdef` to make sure that we use the correct LLDB definition that doesn't
reference C++ keywords. Or to give an example, this is how the expression source
code changes:

Before:
```
#define NULL (nullptr) // injected module definition
#ifndef NULL
#define NULL (__null) // hardcoded LLDB definition
#endif
```

After:
```
#ifndef NULL
#define NULL (__null) // hardcoded LLDB definition
#endif
#ifndef NULL
#define NULL (nullptr) // injected module definition
#endif
```

Fixes rdar://10356912

Reviewed By: shafik

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

show more ...

[lldb] Reject redefinitions of persistent variables

Currently one can redefine a persistent variable and LLDB will just silently
ignore the second definition:

```
(lldb) expr int $i = 1
(lldb) expr

[lldb] Reject redefinitions of persistent variables

Currently one can redefine a persistent variable and LLDB will just silently
ignore the second definition:

```
(lldb) expr int $i = 1
(lldb) expr int $i = 2
(lldb) expr $i
(int) $i = 1
```

This patch makes this an error and rejects the expression with the second
definition.

A nice follow up would be to refactor LLDB's persistent variables to not just be
a pair of type and name, but also contain some way to obtain the original
declaration and source code that declared the variable. That way we could
actually make a full diagnostic as we would get from redefining a variable twice
in the same expression.

Reviewed By: labath, shafik, JDevlieghere

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

show more ...

[lldb] Allow limiting the number of error diagnostics when parsing an expression

While debugging another bug I found out that we currently don't set any limit
for the number of diagnostics Clang emi

[lldb] Allow limiting the number of error diagnostics when parsing an expression

While debugging another bug I found out that we currently don't set any limit
for the number of diagnostics Clang emits. If a user does something that
generates a lot of errors (like including some long header file from within the
expression function), then we currently spam the LLDB output with potentially
thousands of Clang error diagnostics.

Clang sets a default limit of 20 errors, but given that LLDB is often used
interactively for small expressions I would say a limit of 5 is enough. The
limit is implemented as a setting, so if a user cares about seeing having a
million errors printed to their terminal then they can just increase the
settings value.

Reviewed By: shafik, mib

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

show more ...

[lldb] Extract reproducer providers & co into their own header.

Extract all the provider related logic from Reproducer.h and move it
into its own header ReproducerProvider.h. These classes are seein

[lldb] Extract reproducer providers & co into their own header.

Extract all the provider related logic from Reproducer.h and move it
into its own header ReproducerProvider.h. These classes are seeing most
of the development these days and this reorganization reduces
incremental compilation from ~520 to ~110 files when making changes to
the new header.

show more ...

[lldb][NFC] Don't pass around passthrough from ClangDiagnosticManagerAdapter

The passthrough DiagnosticConsumer is an implementation detail of
ClangDiagnosticManagerAdapter and we can just hide it b

[lldb][NFC] Don't pass around passthrough from ClangDiagnosticManagerAdapter

The passthrough DiagnosticConsumer is an implementation detail of
ClangDiagnosticManagerAdapter and we can just hide it behind the normal
DiagnosticConsumer interface that ClangDiagnosticManagerAdapter is supposed
to implement.

show more ...

[lldb][NFC] Fix a variable name in ClangDiagnosticManagerAdapter

[lldb] Use std::make_unique<> (NFC)

Update the rest of lldb to use std::make_unique<>. I used clang-tidy to
automate this, which probably missed cases that are wrapped in ifdefs.

[lldb] Replace calls to new with std::make_shared<> (NFC)

[lldb] Don't print IRForTarget errors directly to the console

Summary:

When we get an error back from IRForTarget we directly print that error to the
debugger output stream instead of putting it in

[lldb] Don't print IRForTarget errors directly to the console

Summary:

When we get an error back from IRForTarget we directly print that error to the
debugger output stream instead of putting it in the result object. The result
object only gets a vague "The expression could not be prepared to run in the
target" error message that doesn't actually tell the user what went wrong.

This patch just puts the IRForTarget errors into the status object that is
returned to the caller instead of directly printing it to the debugger. Also
updates one test that now can actually check for the error message it is
supposed to check for (instead of the default error which is all we had before).

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

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

show more ...

[lldb] Make order of completions for expressions deterministic and sorted by Clang's priority values.

Summary:

It turns out that the order in which we provide completions for expressions is
nondete

[lldb] Make order of completions for expressions deterministic and sorted by Clang's priority values.

Summary:

It turns out that the order in which we provide completions for expressions is
nondeterministic. This leads to confusing user experience and also breaks the
reproducer tests (as two LLDB tests can go out of sync due to the
non-determinism in the completion lists)

The reason for the non-determinism is that the CompletionConsumer informs us
about decls in the order in which it finds declarations in the lookup store of
the DeclContexts it visits (mainly this snippet in SemaLookup.cpp):

``` lang=c++
// Enumerate all of the results in this context.
for (DeclContextLookupResult R :
Load ? Ctx->lookups()
: Ctx->noload_lookups(/*PreserveInternalState=*/false)) {
[...]
```

This storage of the lookup is sorted by pointer values (see the hash of
`DeclarationName`) and can therefore be non-deterministic. The LLDB code
completion consumer that receives these calls originally expected that the order
of declarations is defined by Clang, but it seems the API expects the client to
provide an order to the completions.

This patch fixes the issue as follows:

* We sort the completions we get from Clang alphabetically and also by the
priority value we get from Clang (with priority value sorting having precedence
over the alphabetical sorting)

* We make all the functions/variables that touch a completion before the sorting
const-qualified. The idea is that this should prevent that we never have
observable side-effect from touching these declarations in a non-deterministic
order (e.g., we don't try to complete the type by accident).

This way we behave like the other parts of Clang which also sort the results by
some deterministic value (usually the name or something computed from a name,
e.g., edit distance to a given string).

We most likely also need to fix the Clang code to make the loop I listed above
deterministic to prevent these issues in the future (tracked in rdar://63442513
). This wouldn't replace the functionality provided in this patch though as we
would still need the priority and overall alphabetical sorting.

Note: I had to increase the lldb-vscode completion limit to 100 as the tests
look for strings that aren't in the first 50 results anymore due to variable
names starting with letters like 'v' (which are now always shown much further
down in the list due to the alphabetical sorting).

Fixes rdar://63200995

Reviewers: JDevlieghere, clayborg

Reviewed By: JDevlieghere

Subscribers: mgrang, abidh

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

show more ...