History log of /llvm-project/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp (Results 76 – 100 of 154)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-10.0.0-rc1
# adcd0268 28-Jan-2020 Benjamin Kramer <benny.kra@googlemail.com>

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...


# 80814287 24-Jan-2020 Raphael Isemann <teemperor@gmail.com>

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


Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2
# c16f0b18 26-Nov-2019 Pavel Labath <pavel@labath.sk>

[lldb/cpluspluslanguage] Add constructor substitutor

Summary:
This patch adds code which will substitute references to the full object
constructors/destructors with their base object versions.

Like

[lldb/cpluspluslanguage] Add constructor substitutor

Summary:
This patch adds code which will substitute references to the full object
constructors/destructors with their base object versions.

Like all substitutions in this category, this operation is not really
sound, but doing this in a more precise way allows us to get rid of a
much larger hack -- matching function according to their demangled
names, which effectively does the same thing, but also much more.

This is a (very late) follow-up to D54074.

Background: clang has an optimization which can eliminate full object
structors completely, if they are found to be equivalent to their base
object versions. It does this because it assumes they can be regenerated
on demand in the compile unit that needs them (e.g., because they are
declared inline). However, this doesn't work for the debugging scenario,
where we don't have the structor bodies available -- we pretend all
constructors are defined out-of-line as far as clang is concerned. This
causes clang to emit references to the (nonexisting) full object
structors during expression evaluation.

Fun fact: This is not a problem on darwin, because the relevant
optimization is disabled to work around a linker bug.

Reviewers: teemperor, JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

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

show more ...


Revision tags: llvmorg-9.0.1-rc1
# 506144da 22-Nov-2019 Jordan Rupprecht <rupprecht@google.com>

[lldb][DataFormatters] Support pretty printing std::string when built with -funsigned-char.

Summary:
When built w/ `-funsigned-char`, `std::string` becomes equivalent to `std::basic_string<unsigned

[lldb][DataFormatters] Support pretty printing std::string when built with -funsigned-char.

Summary:
When built w/ `-funsigned-char`, `std::string` becomes equivalent to `std::basic_string<unsigned char>`, causing these formatters to not match. This patch adds overloads for both libstdc++ and libc++ string formatters that accepts unsigned char.

Motivated by the following example:

```
$ cat pretty_print.cc

template <typename T>
void print_val(T s) {
std::cerr << s << '\n'; // Set a breakpoint here!
}

int main() {
std::string val = "hello";
print_val(val);
return 0;
}
$ clang++ -stdlib=libc++ -funsigned-char -fstandalone-debug -g pretty_print.cc
$ lldb ./a.out -b -o 'b pretty_print.cc:6' -o r -o 'fr v'
...
(lldb) fr v
(std::__1::basic_string<unsigned char, std::__1::char_traits<unsigned char>, std::__1::allocator<unsigned char> >) s = {
__r_ = {
std::__1::__compressed_pair_elem<std::__1::basic_string<unsigned char, std::__1::char_traits<unsigned char>, std::__1::allocator<unsigned char> >::__rep, 0, false> = {
__value_ = {
= {
__l = (__cap_ = 122511465736202, __size_ = 0, __data_ = 0x0000000000000000)
__s = {
= (__size_ = '\n', __lx = '\n')
__data_ = {
[0] = 'h'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
[5] = '\0'
...
```

Reviewers: labath, JDevlieghere, shafik

Subscribers: christof, lldb-commits

Tags: #lldb

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

show more ...


# 91e94a70 12-Nov-2019 shafik <syaghmour@apple.com>

[LLDB][Formatters] Re-enable std::function formatter with fixes to improve non-cached lookup performance

Performance issues lead to the libc++ std::function formatter to be disabled. We addressed so

[LLDB][Formatters] Re-enable std::function formatter with fixes to improve non-cached lookup performance

Performance issues lead to the libc++ std::function formatter to be disabled. We addressed some of those performance issues by adding caching see D67111
This PR fixes the first lookup performance by not using FindSymbolsMatchingRegExAndType(...) and instead finding the compilation unit the std::function wrapped callable should be in and then searching for the callable directly in the CU.

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

show more ...


# 83393d27 06-Nov-2019 shafik <syaghmour@apple.com>

[LLDB] Fix handling for the clang name mangling extension for block invocations

Add support for clangs mangling extension for block invocations.

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

[LLDB] Fix handling for the clang name mangling extension for block invocations

Add support for clangs mangling extension for block invocations.

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

show more ...


Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4
# 5aa1d819 04-Sep-2019 Jan Kratochvil <jan.kratochvil@redhat.com>

Code cleanup: Change FormattersContainer::KeyType from SP to rvalue

There is now std::shared_ptr passed around which is expensive for manycore
CPUs. Most of the times (except for 3 cases) it is now

Code cleanup: Change FormattersContainer::KeyType from SP to rvalue

There is now std::shared_ptr passed around which is expensive for manycore
CPUs. Most of the times (except for 3 cases) it is now just std::moved with no
CPU locks needed. It also makes it possible to sort the keys (which is now not
needed much after D66398).

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

llvm-svn: 370863

show more ...


Revision tags: llvmorg-9.0.0-rc3
# b17d6c52 22-Aug-2019 Jan Kratochvil <jan.kratochvil@redhat.com>

[lldb] Fix `TestDataFormatterStdList` regression

Since D66174 I see failures of TestDataFormatterStdList in about 50% of runs on
Fedora 30 x86_64 libstdc++. I have found out that LLDB internally exp

[lldb] Fix `TestDataFormatterStdList` regression

Since D66174 I see failures of TestDataFormatterStdList in about 50% of runs on
Fedora 30 x86_64 libstdc++. I have found out that LLDB internally expects these
RegularExpressions to be matched in their alphabetical order:
^std::(__cxx11::)?list<.+>(( )?&)?$
^std::__[[:alnum:]]+::list<.+>(( )?&)?$

But since D66174 they are sometimes matched in reverse order. In fact it was
only some luck it worked before as there is internally
std::map<lldb::RegularExpressionSP, FormatterImpl> (FormattersContainer).

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

llvm-svn: 369655

show more ...


# c46d39b9 21-Aug-2019 Jonas Devlieghere <jonas@devlieghere.com>

Add char8_t support (C++20)

This patch adds support for the char8_t type introduced in C++20
char8_t. The original patch was submitted by James Blachly on the LLDB
mailing list [1]. I modified the

Add char8_t support (C++20)

This patch adds support for the char8_t type introduced in C++20
char8_t. The original patch was submitted by James Blachly on the LLDB
mailing list [1]. I modified the patch a bit and added a test.

[1] http://lists.llvm.org/pipermail/lldb-dev/2019-August/015393.html

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

llvm-svn: 369582

show more ...


Revision tags: llvmorg-9.0.0-rc2
# c5d40145 02-Aug-2019 Shafik Yaghmour <syaghmour@apple.com>

[Formatters] Temporarily disable libc++ std::function formatter due to performance issue

Summary: We have been seeing increased reports of performance issue around large project and formatting std::

[Formatters] Temporarily disable libc++ std::function formatter due to performance issue

Summary: We have been seeing increased reports of performance issue around large project and formatting std::function variables especially in functions signatures in back traces. There are some possible fixes but exploring those fixes may take time and it is better to temporarily disable the formatter due to its impact and re-enable it once we have a fix.

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

llvm-svn: 367701

show more ...


Revision tags: llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1
# 1756630d 03-May-2019 Raphael Isemann <teemperor@gmail.com>

C.128 override, virtual keyword handling

Summary:
According to [C128] "Virtual functions should specify exactly one
of `virtual`, `override`, or `final`", I've added override where a
virtual functio

C.128 override, virtual keyword handling

Summary:
According to [C128] "Virtual functions should specify exactly one
of `virtual`, `override`, or `final`", I've added override where a
virtual function is overriden but the explicit `override` keyword
was missing. Whenever both `virtual` and `override` were specified,
I removed `virtual`. As C.128 puts it:

> [...] writing more than one of these three is both redundant and
> a potential source of errors.

I anticipate a discussion about whether or not to add `override` to
destructors but I went for it because of an example in [ISOCPP1000].
Let me repeat the comment for you here:

Consider this code:

```
struct Base {
virtual ~Base(){}
};

struct SubClass : Base {
~SubClass() {
std::cout << "It works!\n";
}
};

int main() {
std::unique_ptr<Base> ptr = std::make_unique<SubClass>();
}
```

If for some odd reason somebody removes the `virtual` keyword from the
`Base` struct, the code will no longer print `It works!`. So adding
`override` to destructors actively protects us from accidentally
breaking our code at runtime.

[C128]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final
[ISOCPP1000]: https://github.com/isocpp/CppCoreGuidelines/issues/1000#issuecomment-476951555

Reviewers: teemperor, JDevlieghere, davide, shafik

Reviewed By: teemperor

Subscribers: kwk, arphaman, kadircet, lldb-commits

Tags: #lldb

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

llvm-svn: 359868

show more ...


# abdb816b 24-Apr-2019 Shafik Yaghmour <syaghmour@apple.com>

[DataFormatters] Adjusting libc++ std::list formatter to act better with pointers and references and adding a test to cover a previous related fix

Summary:
This previous fix https://github.com/llvm-

[DataFormatters] Adjusting libc++ std::list formatter to act better with pointers and references and adding a test to cover a previous related fix

Summary:
This previous fix https://github.com/llvm-mirror/lldb/commit/5469bda296c183d1b6bf74597c88c9ed667b3145 did not have a test since we did not have a reproducer.

This is related to how formatters deal with pointers and references. The added tests both the new behavior and covers the previous bug fix as well.

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

llvm-svn: 359118

show more ...


# 8b3af63b 10-Apr-2019 Jonas Devlieghere <jonas@devlieghere.com>

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


Revision tags: llvmorg-8.0.0
# f6a84ed3 14-Mar-2019 Davide Italiano <davide@freebsd.org>

[Python] Start eradicating unneeded LLDB_DISABLE_PYTHON guards.

While we don't have a bot, I'm testing by hand that this configuration
compiles. We'll probably set up one once I'm done flensing.

ll

[Python] Start eradicating unneeded LLDB_DISABLE_PYTHON guards.

While we don't have a bot, I'm testing by hand that this configuration
compiles. We'll probably set up one once I'm done flensing.

llvm-svn: 356171

show more ...


Revision tags: llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2
# 7ba2d3e8 01-Feb-2019 Thomas Anderson <thomasanderson@google.com>

[lldb] Relax libc++ ABI version checking

libc++ has programmable ABI versioning controllable with the _LIBCPP_ABI_VERSION
macro. Currently there are at least 3 settings used in real systems (1 as t

[lldb] Relax libc++ ABI version checking

libc++ has programmable ABI versioning controllable with the _LIBCPP_ABI_VERSION
macro. Currently there are at least 3 settings used in real systems (1 as the
default, ndk1 for Anroid, Cr for Chromium).

Only the 1 and ndk1 cases were handled. This change relaxes the check to allow
any ABI version.

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

llvm-svn: 352899

show more ...


Revision tags: llvmorg-8.0.0-rc1
# 2946cd70 19-Jan-2019 Chandler Carruth <chandlerc@gmail.com>

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


# a6682a41 15-Dec-2018 Jonas Devlieghere <jonas@devlieghere.com>

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


Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3
# ceff6644 11-Nov-2018 Jonas Devlieghere <jonas@devlieghere.com>

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


# e0d2733b 06-Nov-2018 Pavel Labath <pavel@labath.sk>

CPlusPlusLanguage: Use new demangler API to implement type substitution

Summary:
Now that llvm demangler supports more generic customization, we can
implement type substitution directly on top of th

CPlusPlusLanguage: Use new demangler API to implement type substitution

Summary:
Now that llvm demangler supports more generic customization, we can
implement type substitution directly on top of this API. This will allow
us to remove the specialized hooks which were added to the demangler to
support this use case.

Reviewers: sgraenitz, erik.pilkington, JDevlieghere

Subscribers: lldb-commits

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

llvm-svn: 346233

show more ...


# c1e530ee 06-Nov-2018 Aleksandr Urakov <aleksandr.urakov@jetbrains.com>

[PDB] Introduce `MSVCUndecoratedNameParser`

This patch introduces the simple MSVCUndecoratedNameParser. It is needed for
parsing names of PDB symbols corresponding to template instantiations. For
ex

[PDB] Introduce `MSVCUndecoratedNameParser`

This patch introduces the simple MSVCUndecoratedNameParser. It is needed for
parsing names of PDB symbols corresponding to template instantiations. For
example, for the name `operator<<A>'::`2'::B::operator> we can't just split the
name with :: (as it is implemented for now) to retrieve its scopes. This parser
processes such names in a more correct way.

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

llvm-svn: 346213

show more ...


Revision tags: llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1
# 693fbf5c 26-Oct-2018 Shafik Yaghmour <syaghmour@apple.com>

[DataFormatters] Adding formatters for libc++ std::u16string and std::u32string

rdar://problem/41302849

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

llvm-svn: 345402


# 8306f76e 19-Sep-2018 Shafik Yaghmour <syaghmour@apple.com>

[DataFormatters] Add formatter for C++17 std::variant

rdar://problem/43691454

Patch by Shafik Yaghmour.

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

llvm-svn: 342563


# 2ee93d28 17-Sep-2018 Shafik Yaghmour <syaghmour@apple.com>

Revert "[DataFormatters] Add formatter for C++17 std::variant"

This reverts commit r342421.

Because it breaks build bot http://green.lab.llvm.org/green/job/lldb-cmake-clang-5.0.2//418/console

llvm

Revert "[DataFormatters] Add formatter for C++17 std::variant"

This reverts commit r342421.

Because it breaks build bot http://green.lab.llvm.org/green/job/lldb-cmake-clang-5.0.2//418/console

llvm-svn: 342424

show more ...


# 854a3509 17-Sep-2018 Shafik Yaghmour <syaghmour@apple.com>

[DataFormatters] Add formatter for C++17 std::variant

rdar://problem/43691454

Patch by Shafik Yaghmour.

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

llvm-svn: 342421


Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3
# 6b58fa71 23-Aug-2018 Adrian Prantl <aprantl@apple.com>

Add libc++ data formatter for std::function

- Added LibcxxFunctionSummaryProvider
- Removed LibcxxFunctionFrontEnd
- Modified data formatter tests to test new summary functionality

Patch by Shafik

Add libc++ data formatter for std::function

- Added LibcxxFunctionSummaryProvider
- Removed LibcxxFunctionFrontEnd
- Modified data formatter tests to test new summary functionality

Patch by Shafik Yaghmour!

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

llvm-svn: 340543

show more ...


1234567