[lldb][NFC] Allow range-based for-loops on VariableList

Summary:
Adds support for doing range-based for-loops on LLDB's VariableList and
modernises all the index-based for-loops in LLDB where possib

[lldb][NFC] Allow range-based for-loops on VariableList

Summary:
Adds support for doing range-based for-loops on LLDB's VariableList and
modernises all the index-based for-loops in LLDB where possible.

Reviewers: labath, jdoerfert

Reviewed By: labath

Subscribers: JDevlieghere, lldb-commits

Tags: #lldb

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

show more ...

[lldb][NFC] Remove strange bool parameter from Searcher::SearchCallback

Summary:
The SearchCallback has a bool parameter that we always set to false, we never use in any callback implementation and

[lldb][NFC] Remove strange bool parameter from Searcher::SearchCallback

Summary:
The SearchCallback has a bool parameter that we always set to false, we never use in any callback implementation and that also changes its name
from one file to the other (either `containing` and `complete`). It was added in the original LLDB check in, so there isn't any history what
this was supposed to be, so let's just remove it.

Reviewers: jingham, JDevlieghere, labath

Reviewed By: jingham, labath

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 374313

show more ...

Convert FileSystem::Open() to return Expected<FileUP>

Summary:
This patch converts FileSystem::Open from this prototype:

Status
Open(File &File, const FileSpec &file_spec, ...);

to this one:

llvm

Convert FileSystem::Open() to return Expected<FileUP>

Summary:
This patch converts FileSystem::Open from this prototype:

Status
Open(File &File, const FileSpec &file_spec, ...);

to this one:

llvm::Expected<std::unique_ptr<File>>
Open(const FileSpec &file_spec, ...);

This is beneficial on its own, as llvm::Expected is a more modern
and recommended error type than Status. It is also a necessary step
towards https://reviews.llvm.org/D67891, and further developments
for lldb_private::File.

Reviewers: JDevlieghere, jasonmolenda, labath

Reviewed By: labath

Subscribers: mgorny, lldb-commits

Tags: #lldb

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

llvm-svn: 373003

show more ...

[lldb] D66174 `RegularExpression` cleanup

I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI
as an advantage and there is already constructor parameter to compile the
re

[lldb] D66174 `RegularExpression` cleanup

I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI
as an advantage and there is already constructor parameter to compile the
regex.

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

llvm-svn: 369352

show more ...

[Utility] Reimplement RegularExpression on top of llvm::Regex

Originally I wanted to remove the RegularExpression class in Utility and
replace it with llvm::Regex. However, during that transition I

[Utility] Reimplement RegularExpression on top of llvm::Regex

Originally I wanted to remove the RegularExpression class in Utility and
replace it with llvm::Regex. However, during that transition I noticed
that there are several places where need the regular expression string.
So instead I propose to keep the RegularExpression class and make it a
thin wrapper around llvm::Regex.

This patch also removes the workaround for empty regular expressions.
The result is that we are now (more or less) POSIX conformant.

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

llvm-svn: 369153

show more ...

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)

This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style for

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)

This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.

So instead of writing:

if (log)
log->Printf("%s\n", str);

You'd write:

LLDB_LOG(log, "%s\n", str);

This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.

find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +

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

llvm-svn: 366936

show more ...

[CplusPlus] ISVTableName is unused. NFCI.

Reviewers: teemperor, JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 365243

[LanguageRuntime] Introduce LLVM-style casts

Summary:
Using llvm-style rtti gives us stronger guarantees around casting
LanguageRuntimes.

As discussed in D62755

Differential Revision: https://revi

[LanguageRuntime] Introduce LLVM-style casts

Summary:
Using llvm-style rtti gives us stronger guarantees around casting
LanguageRuntimes.

As discussed in D62755

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

llvm-svn: 362884

show more ...

Replace assert with static_assert here applicable.

Replaces assert() with static_assert() if the condition is can be
evaluated at compile time.

llvm-svn: 360753

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

Pass ConstString by value (NFC)

My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.

ConstString has exactly one const char * data member, s

Pass ConstString by value (NFC)

My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.

ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.

(This fixes rdar://problem/48640859 for the Apple folks)

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

llvm-svn: 355553

show more ...

Replace 'ap' with 'up' suffix in variable names. (NFC)

The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique

Replace 'ap' with 'up' suffix in variable names. (NFC)

The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.

In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.

I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.

llvm-svn: 353912

show more ...

Use std::make_shared in LLDB (NFC)

Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared

Use std::make_shared in LLDB (NFC)

Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.

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

llvm-svn: 353764

show more ...

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

Simplify Boolean expressions

This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:

run-clang-tidy.py -checks='-*,readability-simplify-

Simplify Boolean expressions

This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:

run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD

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

llvm-svn: 349215

show more ...

Re-land "Extract construction of DataBufferLLVM into FileSystem"

This fixes some UB in isLocal detected by the sanitized bot.

llvm-svn: 346707

Revert "Extract construction of DataBufferLLVM into FileSystem"

It broke the lldb sanitizer bots.

llvm-svn: 346694

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

Extract construction of DataBufferLLVM into FileSystem

This moves construction of data buffers into the FileSystem class. Like
some of the previous refactorings we don't translate the path yet
becau

Extract construction of DataBufferLLVM into FileSystem

This moves construction of data buffers into the FileSystem class. Like
some of the previous refactorings we don't translate the path yet
because the functionality hasn't been landed in LLVM yet.

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

llvm-svn: 346598

show more ...

[FileSystem] Open File instances through the FileSystem.

This patch modifies how we open File instances in LLDB. Rather than
passing a path or FileSpec to the constructor, we now go through the
virt

[FileSystem] Open File instances through the FileSystem.

This patch modifies how we open File instances in LLDB. Rather than
passing a path or FileSpec to the constructor, we now go through the
virtual file system. This is needed in order to make things work with
the VFS in the future.

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

llvm-svn: 346049

show more ...

[FileSystem] Move path resolution logic out of FileSpec

This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.

Differential

[FileSystem] Move path resolution logic out of FileSpec

This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.

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

llvm-svn: 345890

show more ...

[FileSystem] Remove Exists() from FileSpec

This patch removes the Exists method from FileSpec and updates its uses
with calls to the FileSystem.

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

[FileSystem] Remove Exists() from FileSpec

This patch removes the Exists method from FileSpec and updates its uses
with calls to the FileSystem.

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

llvm-svn: 345854

show more ...

[FileSystem] Remove GetPermissions() and Readable() from FileSpec

This patch removes the GetPermissions and GetReadable methods from
FileSpec and updates its uses with calls to the FileSystem.

Diff

[FileSystem] Remove GetPermissions() and Readable() from FileSpec

This patch removes the GetPermissions and GetReadable methods from
FileSpec and updates its uses with calls to the FileSystem.

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

llvm-svn: 345843

show more ...

Don't type-erase the SymbolContextItem enumeration.

When we get the `resolve_scope` parameter from the SB API, it's a
`uint32_t`. We then pass it through all of LLDB this way, as a uint32.
This is

Don't type-erase the SymbolContextItem enumeration.

When we get the `resolve_scope` parameter from the SB API, it's a
`uint32_t`. We then pass it through all of LLDB this way, as a uint32.
This is unfortunate, because it means the user of an API never actually
knows what they're dealing with. We can call it something like
`resolve_scope` and have comments saying "this is a value from the
`SymbolContextItem` enumeration, but it makes more sense to just have it
actually *be* the correct type in the actual C++ type system to begin
with. This way the person reading the code just knows what it is.

The reason to use integers instead of enumerations for flags is because
when you do bitwise operations on enumerations they get promoted to
integers, so it makes it tedious to constantly be casting them back
to the enumeration types, so I've introduced a macro to make this
happen magically. By writing LLDB_MARK_AS_BITMASK_ENUM after defining
an enumeration, it will define overloaded operators so that the
returned type will be the original enum. This should address all
the mechanical issues surrounding using rich enum types directly.

This way, we get a better debugger experience, and new users to
the codebase can get more easily acquainted with the codebase because
their IDE features can help them understand what the types mean.

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

llvm-svn: 345313

show more ...

Revert "Return a named error in the result object of an expression with no result"

This reverts commit r344647.
This causes build failures with [-Werror, -Wswitch]. Some cases where the newly
introd

Revert "Return a named error in the result object of an expression with no result"

This reverts commit r344647.
This causes build failures with [-Werror, -Wswitch]. Some cases where the newly
introduced enum value is not handled in particular are in:
lldb/source/Expression/REPL.cpp:350
lldb/source/Interpreter/CommandInterpreter.cpp:1529
(maybe there could be more)

As I don't understand lldb to make sure the likely trivial fixes are
correct and also as they might need additional tests, leaving to the
author to resolve.

llvm-svn: 344722

show more ...