[LLDB] Fix compilation with GCC 5

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

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

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

show more ...

Remove TypeValidators (NFC in terms of the testsuite)

This is a half-implemented feature that as far as we can tell was
never used by anything since its original inclusion in 2014. This
patch remove

Remove TypeValidators (NFC in terms of the testsuite)

This is a half-implemented feature that as far as we can tell was
never used by anything since its original inclusion in 2014. This
patch removes it to make remaining the code easier to understand.

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

show more ...

Remove unsound caching in LanguageCategory

Analogous to https://reviews.llvm.org/D71233 it is not safe to cache
something that depends on the actual ValueObject in a cache then keys
only off the typ

Remove unsound caching in LanguageCategory

Analogous to https://reviews.llvm.org/D71233 it is not safe to cache
something that depends on the actual ValueObject in a cache then keys
only off the type name.

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

show more ...

Replace redundant code in LanguageCategory with templates (NFC)

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

[DataFormatters] Change the Get() method to take a LanguageType.

Suggested by Adrian.

Replace redundant code in FormatManager and FormatCache with templates (NFC)

This is a preparatory patch for an upcoming bugfix.

FormatManager and friends have four identical implementations of man

Replace redundant code in FormatManager and FormatCache with templates (NFC)

This is a preparatory patch for an upcoming bugfix.

FormatManager and friends have four identical implementations of many
accessor functions to deal with the four types of shared pointers in
the FormatCache. This patch replaces these implementations with
templates. While this patch drastically reduces the amount of source
code and its maintainablity, it doesn't actually improve code
size. I'd argue, this is still an improvement.

rdar://problem/57756763

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

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

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

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.

llvm-svn: 280751

show more ...

Fix a bug where language categories would hold on to their caches even after changes

llvm-svn: 255603

Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be

Th

Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be

This is a NFC commit that is essentially plumbing the new currency through the system

llvm-svn: 249366

show more ...

Move hardcoded formatters from the FormatManager to the Language plugins

llvm-svn: 247831

Move Objective-C data formatters to the Objective-C language plugin where they belong

llvm-svn: 247627

Move the C++ data formatters to the C++ language plugin

llvm-svn: 246873

Add support for language plugins to provide data formatters (second attempt)

Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be

Add support for language plugins to provide data formatters (second attempt)

Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex)

This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on
The advantages of this are:
a) language formatters only get created when they might apply
b) formatters for a language are clearly owned by the matching language plugin

The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager
In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters

No formatters are moved as part of this change, so practically speaking this is NFC

llvm-svn: 246568

show more ...

Add support for language plugins to provide data formatters

Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when

Add support for language plugins to provide data formatters

Historically, data formatters all exist in a global repository (the category map)
On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex)

This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on
The advantages of this are:
a) language formatters only get created when they might apply
b) formatters for a language are clearly owned by the matching language plugin

The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager
In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters

No formatters are moved as part of this change, so practically speaking this is NFC

llvm-svn: 246515

show more ...