[llvm] [Demangle] Fix MSVC demangling for placeholder return types (#106178)

Properly demangle `_T` and `_P` return type manglings for MSVC 1920+.
Also added a unit test for `@` return type that is

[llvm] [Demangle] Fix MSVC demangling for placeholder return types (#106178)

Properly demangle `_T` and `_P` return type manglings for MSVC 1920+.
Also added a unit test for `@` return type that is used when mangling
non-template auto placeholder return type function.

Tested the output against the undname shipped with MSVC 19.40.

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] 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] Add StringView conversion operator

The OutputBuffer class tries to present a NUL-terminated string API to
consumers. But several of them would prefer a StringView. In
particular the Mi

[demangler] Add StringView conversion operator

The OutputBuffer class tries to present a NUL-terminated string API to
consumers. But several of them would prefer a StringView. In
particular the Microsoft demangler, juggles between NUL-terminated and
StringView, which is confusing.

This adds a StringView conversion, and adjusts the Demanglers that can
benefit from that.

Reviewed By: dblaikie

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

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

[lldb] change name demangling to be consistent between windows and linx

When printing names in lldb on windows these names contain the full type information while on linux only the name is contained

[lldb] change name demangling to be consistent between windows and linx

When printing names in lldb on windows these names contain the full type information while on linux only the name is contained.

This change introduces a flag in the Microsoft demangler to control if the type information should be included.
With the flag enabled demangled name contains only the qualified name, e.g:
without flag -> with flag
int (*array2d)[10] -> array2d
int (*abc::array2d)[10] -> abc::array2d
const int *x -> x

For globals there is a second inconsistency which is not yet addressed by this change. On linux globals (in global namespace) are prefixed with :: while on windows they are not.

Reviewed By: teemperor, rnk

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

show more ...

[Clang] Introduce Swift async calling convention.

This change is intended as initial setup. The plan is to add
more semantic checks later. I plan to update the documentation
as more semantic checks

[Clang] Introduce Swift async calling convention.

This change is intended as initial setup. The plan is to add
more semantic checks later. I plan to update the documentation
as more semantic checks are added (instead of documenting the
details up front). Most of the code closely mirrors that for
the Swift calling convention. Three places are marked as
[FIXME: swiftasynccc]; those will be addressed once the
corresponding convention is introduced in LLVM.

Reviewed By: rjmccall

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

show more ...

Fix memory leak in MicrosoftDemangleNodes's Node::toString

The buffer we turn into a std::string here is malloc'd and should be
free'd before we return from this function.

Follow up to LLDB leak fi

Fix memory leak in MicrosoftDemangleNodes's Node::toString

The buffer we turn into a std::string here is malloc'd and should be
free'd before we return from this function.

Follow up to LLDB leak fixes such as D100806.

Reviewed By: mstorsjo, rupprecht, MaskRay

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

show more ...

[Demangle] Support demangling Swift calling convention in MS demangler.

Previously, Clang was able to mangle the Swift calling
convention but 'MicrosoftDemangle.cpp' was not able to demangle it.

Re

[Demangle] Support demangling Swift calling convention in MS demangler.

Previously, Clang was able to mangle the Swift calling
convention but 'MicrosoftDemangle.cpp' was not able to demangle it.

Reviewed By: compnerd, rnk

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

show more ...

[llvm] Remove redundant return and continue statements (NFC)

Identified with readability-redundant-control-flow.

[Demangle] Add a few more options to the microsoft demangler

This corresponds to commonly used options to UnDecorateSymbolName
within llvm.

Add them as hidden options in llvm-undname. MS undname.ex

[Demangle] Add a few more options to the microsoft demangler

This corresponds to commonly used options to UnDecorateSymbolName
within llvm.

Add them as hidden options in llvm-undname. MS undname.exe takes
numeric flags, corresponding to the UNDNAME_* constants, but instead
of hardcoding in mappings for those numbers, just add textual
options instead, as it the use of them here is primarily intended
for testing.

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

llvm-svn: 374865

show more ...

llvm-undname: Delete an empty, unused method.

llvm-svn: 372367

llvm-undname: Correctly demangle vararg parameters

FunctionSignatureNode already had an IsVariadic field,
but it wasn't used anywhere yet. Set it and use it.

llvm-svn: 362541

llvm-undname: Several behavior-preserving changes to increase coverage

- Replace `Error = true` in a few branches that are truly unreachable
with DEMANGLE_UNREACHABLE

- Remove early return early

llvm-undname: Several behavior-preserving changes to increase coverage

- Replace `Error = true` in a few branches that are truly unreachable
with DEMANGLE_UNREACHABLE

- Remove early return early in startsWithLocalScopePattern() because
it's redundant with the next two early returns

- Remove unreachable `case '0'` (it's handled in the branch below)

- Remove an unused bool return

- Add test coverage for several early error returns, mostly in
array type parsing

llvm-svn: 362506

show more ...

llvm-undname: Support demangling char8_t

Ports clang's mangling support added in r354633 to llvm-undname.

llvm-svn: 361839

llvm-undname: Add support for local static thread guards

llvm-svn: 361835

llvm-undname: Support demangling the spaceship operator

Also add a test for demanling the co_await operator.

llvm-svn: 359007

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

NFC: Make the copies of the demangler byte-for-byte identical

With this patch, the copies of the files ItaniumDemangle.h,
StringView.h, and Utility.h are kept byte-for-byte in sync between
libcxxabi

NFC: Make the copies of the demangler byte-for-byte identical

With this patch, the copies of the files ItaniumDemangle.h,
StringView.h, and Utility.h are kept byte-for-byte in sync between
libcxxabi and llvm. All differences (namespaces, fallthrough, and
unreachable macros) are defined in each copies' DemanglerConfig.h.

This patch also adds a script to copy changes from libcxxabi
(cp-to-llvm.sh), and a README.txt explaining the situation.

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

llvm-svn: 351474

show more ...

[llvm-undname] Add support for demangling msvc's noexcept types.

Starting in C++17, MSVC introduced a new mangling for function
parameters that are themselves noexcept functions. This patch
makes l

[llvm-undname] Add support for demangling msvc's noexcept types.

Starting in C++17, MSVC introduced a new mangling for function
parameters that are themselves noexcept functions. This patch
makes llvm-undname properly demangle them.

Patch by Zachary Henkel
Differential Revision: https://reviews.llvm.org/D55769

llvm-svn: 350656

show more ...