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

Identified with readability-redundant-member-init.

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

This is an NFC cleanup.

Many of the API's that returned BreakpointOptions always returned valid ones.
Internally the BreakpointLocations usually have null BreakpointOptions, since they
use their owner's options until an option is set specifically on the location.
So the original code used pointers & unique_ptr everywhere for consistency.
But that made the code hard to reason about from the outside.

This patch changes the code so that everywhere an API is guaranteed to
return a non-null BreakpointOption, it returns it as a reference to make
that clear.

It also changes the Breakpoint to hold a BreakpointOption
member where it previously had a UP.  Since we were always filling the UP
in the Breakpoint constructor, having the UP wasn't helping anything.

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

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

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

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

For = operators for lists that have mutexes, we were either
just taking the locks sequentially or hand-rolling a trick
to try to avoid lock inversion.  Use the std::lock mechanism
for this instead.

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

llvm-svn: 357276

the collection lock before we iterate over the owners calling ShouldStop.

BreakpointSite::ShouldStop can do a lot of work, and might by chance hit the same breakpoint
site again on another thread.  So instead of holding the site's owners lock
while iterating over them calling ShouldStop, I make a local copy of the list, drop the lock 
and then iterate over the copy calling BreakpointLocation::ShouldStop.

It's actually quite difficult to make this cause problems because usually all the
action happens on the private state thread, and the lock is recursive.

I have a report where some code hit the ASAN error breakpoint, went to 
compile the ASAN error gathering expression, in the course of compiling
that we went to fetch the ObjC runtime data, but the state of the program
was such that the ObjC runtime grubbing function triggered an ASAN error and 
we were executing that function on another thread.  

I couldn't figure out a way to reproduce that situation in a test.  But this is an 
NFC change anyway, it just makes the locking strategy more narrowly focused.

<rdar://problem/49074093>

llvm-svn: 357141

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