[llvm-cxxfilt] Added the option --no-params (#75348)

Added -p / --no-params flag to skip demangling function parameters
similar to how it is supported by GNU c++filt tool.

There are cases when user

[llvm-cxxfilt] Added the option --no-params (#75348)

Added -p / --no-params flag to skip demangling function parameters
similar to how it is supported by GNU c++filt tool.

There are cases when users want to demangle a large number of symbols in
bulk, for example, at startup, and do not care about function parameters
and overloads at that time. Skipping the demangling of parameter types
led to a measurable improvement in performance. Our users reported about
15% speed up with GNU c++filt and we expect similar results with
llvm-cxxfilt with this patch.

show more ...

Revert "[llvm-cxxfilt] Added the option --no-params (#75348)"

This reverts commit 71f8ea3062a6b0a190835853ee77e58469763b9e.

Test doesn't pass on mac. See comments on
https://github.com/llvm/llvm-pr

Revert "[llvm-cxxfilt] Added the option --no-params (#75348)"

This reverts commit 71f8ea3062a6b0a190835853ee77e58469763b9e.

Test doesn't pass on mac. See comments on
https://github.com/llvm/llvm-project/pull/75348.

show more ...

[llvm-cxxfilt] Added the option --no-params (#75348)

Added -p / --no-params flag to skip demangling function parameters
similar to how it is supported by GNU c++filt tool.

There are cases when u

[llvm-cxxfilt] Added the option --no-params (#75348)

Added -p / --no-params flag to skip demangling function parameters
similar to how it is supported by GNU c++filt tool.

There are cases when users want to demangle a large number of symbols in
bulk, for example, at startup, and do not care about function parameters
and overloads at that time. Skipping the demangling of parameter types
led to a measurable improvement in performance. Our users reported about
15% speed up with GNU c++filt and we expect similar results with
llvm-cxxfilt with this patch.

show more ...

[Demangle] Include <exception> for IWYU

The called std::terminate currently gets the declaration transitively
through llvm/Demangle/Utility.h, removing <exception> from Utility.h
would break Itanium

[Demangle] Include <exception> for IWYU

The called std::terminate currently gets the declaration transitively
through llvm/Demangle/Utility.h, removing <exception> from Utility.h
would break ItaniumDemangle.cpp.

show more ...

[Demangle] use std::string_view::data rather than &*std::string_view::begin

To fix expensive check builds that were failing when using MSVC's
std::string_view::iterator::operator*, I added a few exp

[Demangle] use std::string_view::data rather than &*std::string_view::begin

To fix expensive check builds that were failing when using MSVC's
std::string_view::iterator::operator*, I added a few expressions like
&*std::string_view::begin. @nico pointed out that this is literally the
same thing and more clearly expressed as std::string_view::data.

Link: https://github.com/llvm/llvm-project/issues/63740

Reviewed By: #libc_abi, ldionne, philnik, MaskRay

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

show more ...

[Demangle] convert itaniumDemangle and nonMicrosoftDemangle to use std::string_view

D149104 converted llvm::demangle to use std::string_view. Enabling
"expensive checks" (via -DLLVM_ENABLE_EXPENSIVE

[Demangle] convert itaniumDemangle and nonMicrosoftDemangle to use std::string_view

D149104 converted llvm::demangle to use std::string_view. Enabling
"expensive checks" (via -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON) causes
lld/test/wasm/why-extract.s to fail. The reason for this is obscure:

Reason #10007 why std::string_view is dangerous:
Consider the following pattern:

std::string_view s = ...;
const char *c = s.data();
std::strlen(c);

Is c a NUL-terminated C style string? It depends; but if it's not then
it's not safe to call std::strlen on the std::string_view::data().
std::string_view::length() should be used instead.

Fixing this fixes the one lone test that caught this.

microsoftDemangle, rustDemangle, and dlangDemangle should get this same
treatment, too. I will do that next.

Reviewed By: MaskRay, efriedma

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

show more ...

[Demangle] remove unused status param of itaniumDemangle

No call sites interpreted this value meaningfully. Simplify this
interface.

Reviewed By: MaskRay

Differential Revision: https://reviews.llv

[Demangle] remove unused status param of itaniumDemangle

No call sites interpreted this value meaningfully. Simplify this
interface.

Reviewed By: MaskRay

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

show more ...

[Demangle] remove unused params of itaniumDemangle

No call sites use these parameters, so drop them.
Equivalent to D148940.

Reviewed By: MaskRay

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

[Demangle] remove unused params of itaniumDemangle

No call sites use these parameters, so drop them.
Equivalent to D148940.

Reviewed By: MaskRay

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

show more ...

Reland: [Demangle] replace use of llvm::StringView w/ std::string_view

This reverts commit d81cdb49d74064e88843733e7da92db865943509.

This refactoring was waiting on converting LLVM to C++17.

Leave

Reland: [Demangle] replace use of llvm::StringView w/ std::string_view

This reverts commit d81cdb49d74064e88843733e7da92db865943509.

This refactoring was waiting on converting LLVM to C++17.

Leave StringView.h and cleanup around for subsequent cleanup.

Additional fixes for missing std::string_view conversions for MSVC.

Reviewed By: MaskRay, DavidSpickett, ayzhao

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

show more ...

Revert D148384 "[Demangle] replace use of llvm::StringView w/ std::string_view"

This reverts commit 3e559509b426b6aae735a7f57dbdaed1041d2622 and e0c4ffa796b553fa78c638a9584c05ac21fe07d5.

This still

Revert D148384 "[Demangle] replace use of llvm::StringView w/ std::string_view"

This reverts commit 3e559509b426b6aae735a7f57dbdaed1041d2622 and e0c4ffa796b553fa78c638a9584c05ac21fe07d5.

This still breaks Windows builds.

In addition, `#include <llvm/ADT/StringViewExtras.h>` in
llvm/include/llvm/Demangle/ItaniumDemangle.h is a library layering violation
(LLVMDemangle is the lowest LLVM library and cannot depend on LLVMSupport).

show more ...

[Demangle] fix windows build

Fixes diagnostics reported against
https://reviews.llvm.org/D148384

https://lab.llvm.org/buildbot/#/builders/127/builds/46749/steps/4/logs/stdio

Reviewed By: MaskRay

[Demangle] fix windows build

Fixes diagnostics reported against
https://reviews.llvm.org/D148384

https://lab.llvm.org/buildbot/#/builders/127/builds/46749/steps/4/logs/stdio

Reviewed By: MaskRay

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

show more ...

[Demangle] replace use of llvm::StringView w/ std::string_view

This refactoring was waiting on converting LLVM to C++17.

Leave StringView.h and cleanup around for subsequent cleanup.

Reviewed By:

[Demangle] replace use of llvm::StringView w/ std::string_view

This refactoring was waiting on converting LLVM to C++17.

Leave StringView.h and cleanup around for subsequent cleanup.

Reviewed By: MaskRay

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

show more ...

[demangler] Simplify OutputBuffer initialization

Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need

[demangler] Simplify OutputBuffer initialization

Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need to do that, given recent changes to the buffer extension
heuristics -- it allocates a 1k(ish) buffer on first need.

Just pass in a buffer (if any) to the constructor. Thus the
OutputBuffer's ownership of the buffer starts at its own lifetime
start. We can reduce the lifetime of this object in several cases.

That new constructor takes a 'size_t *' for the size argument, as all
uses with a non-null buffer are passing through a malloc'd buffer from
their own caller in this manner.

The buffer reset member function is never used, and is deleted.

Some adjustment to a couple of uses is needed, due to the lazy buffer
creation of this patch.

a) the Microsoft demangler can demangle empty strings to nothing,
which it then memoizes. We need to avoid the UB of passing nullptr to
memcpy.

b) a unit test checks insertion of no characters into an empty buffer.
We need to avoid UB when converting that to std::string.

The original buffer initialization code would return a failure code if
that first malloc failed. Existing code either ignored that, called
std::terminate with a FIXME, or returned an error code.

But that's not foolproof anyway, as a subsequent buffer extension
failure ends up calling std::terminate. I am working on addressing
that unfortunate failure mode in a manner more consistent with the C++
ABI design.

Reviewed By: dblaikie

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

show more ...

Revert "[demangler] Simplify OutputBuffer initialization"

Reverting due to a bot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/22738

This reverts commit 5b3ca24a35e91bf9c19af856e7f92c6

Revert "[demangler] Simplify OutputBuffer initialization"

Reverting due to a bot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/22738

This reverts commit 5b3ca24a35e91bf9c19af856e7f92c69b17f989e.

show more ...

[demangler] Simplify OutputBuffer initialization

Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need

[demangler] Simplify OutputBuffer initialization

Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need to do that, given recent changes to the buffer extension
heuristics -- it allocates a 1k(ish) buffer on first need.

Just pass in a buffer (if any) to the constructor. Thus the
OutputBuffer's ownership of the buffer starts at its own lifetime
start. We can reduce the lifetime of this object in several cases.

That new constructor takes a 'size_t *' for the size argument, as all
uses with a non-null buffer are passing through a malloc'd buffer from
their own caller in this manner.

The buffer reset member function is never used, and is deleted.

The original buffer initialization code would return a failure code if
that first malloc failed. Existing code either ignored that, called
std::terminate with a FIXME, or returned an error code.

But that's not foolproof anyway, as a subsequent buffer extension
failure ends up calling std::terminate. I am working on addressing
that unfortunate failure mode in a manner more consistent with the C++
ABI design.

Reviewed By: dblaikie

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

show more ...

[demangler] Node precision dumper

Add contents to the demangler node dumper's print(Prec) functions.

Reviewed By: dblaikie

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

ItaniumDemangler: Update BinaryExpr::match to match the ctor

Not sure if this could use more testing, but hopefully this is adequate.

[demangler] Add support for C++20 modules

Add support for module name demangling. We have two new demangler
nodes -- ModuleName and ModuleEntity. The former represents a module
name in a hierarchic

[demangler] Add support for C++20 modules

Add support for module name demangling. We have two new demangler
nodes -- ModuleName and ModuleEntity. The former represents a module
name in a hierarchical fashion. The latter is the combination of a
(name) node and a module name. Because module names and entity
identities use the same substitution encoding, we have to adjust the
flow of how substitutions are handled, and examine the substituted
node to know how to deal with it.

Reviewed By: dblaikie

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

show more ...

[demangler] Remove StdQualifiedName

The StdQualifiedName node class is used for names exactly in the std
namespace. It is not used for nested names that descend further --
those use a NestedName wi

[demangler] Remove StdQualifiedName

The StdQualifiedName node class is used for names exactly in the std
namespace. It is not used for nested names that descend further --
those use a NestedName with NameType("std") as the scope.
Representing the compression scheme in the node graph is layer
breaking. We can use the same structure for those exactly in std too,
and reduce code size a bit.

Reviewed By: ChuanqiXu

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

show more ...

[llvm] Remove unused headers in LLVMDemangle

As an hint to the impact of the cleanup, running

clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Demangle/*.cpp -std=c++14 -fno-rtti -fno-exceptions

[llvm] Remove unused headers in LLVMDemangle

As an hint to the impact of the cleanup, running

clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Demangle/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l

before: 208053 lines
after: 203965 lines

show more ...

[Demangle] Rename OutputStream to OutputString

This patch is a refactor to implement prepend afterwards. Since this changes a lot of files and to conform with guidelines, I will separate this from t

[Demangle] Rename OutputStream to OutputString

This patch is a refactor to implement prepend afterwards. Since this changes a lot of files and to conform with guidelines, I will separate this from the implementation of prepend. Related to the discussion in https://reviews.llvm.org/D111414 , so please read it for more context.

Reviewed By: #libc_abi, dblaikie, ldionne

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

show more ...

Use std::foo_t rather than std::foo in LLVM.

Summary: C++14 migration. No functional change.

Reviewers: bkramer, JDevlieghere, lebedev.ri

Subscribers: MatzeB, hiraditya, jkorous, dexonsmith, arpha

Use std::foo_t rather than std::foo in LLVM.

Summary: C++14 migration. No functional change.

Reviewers: bkramer, JDevlieghere, lebedev.ri

Subscribers: MatzeB, hiraditya, jkorous, dexonsmith, arphaman, kadircet, lebedev.ri, usaxena95, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

show more ...

[demangle] NFC: get rid of NodeOrString

This class was a bit overengineered, and was triggering some PVS warnings.
Instead, put strings into a NameType and let clients unconditionally treat it
as a

[demangle] NFC: get rid of NodeOrString

This class was a bit overengineered, and was triggering some PVS warnings.
Instead, put strings into a NameType and let clients unconditionally treat it
as a Node.

show more ...

Synchronize LLVM's copy of libc++abi's demangler with the libc++abi
version after r371273.

Also fix a minor issue in r371273 that only surfaced after template
instantiation from LLVM's use of the de

Synchronize LLVM's copy of libc++abi's demangler with the libc++abi
version after r371273.

Also fix a minor issue in r371273 that only surfaced after template
instantiation from LLVM's use of the demangler.

llvm-svn: 371274

show more ...

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

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: 351648

show more ...