[llvm][aarch64] Fix Arm64EC name mangling algorithm (#115567)

Arm64EC uses a special name mangling mode that adds `$$h` between the
symbol name and its type. In MSVC's name mangling `@` is used to

[llvm][aarch64] Fix Arm64EC name mangling algorithm (#115567)

Arm64EC uses a special name mangling mode that adds `$$h` between the
symbol name and its type. In MSVC's name mangling `@` is used to
separate the name and type BUT it is also used for other purposes, such
as the separator between paths in a fully qualified name.

The original algorithm was quite fragile and made assumptions that
didn't hold true for all MSVC mangled symbols, so instead of trying to
improve this algorithm we are now using the demangler to indicate where
the insertion point should be (i.e., to parse the fully-qualified name
and return the current string offset).

Also fixed `isArm64ECMangledFunctionName` to search for `@$$h` since the
`$$h` must always be after a `@`.

Fixes #115231

show more ...

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

Fix MSVC 1920+ auto NTTP mangling for pointers to members (#97007)

Fixes https://github.com/llvm/llvm-project/issues/70899.

This is a continuation of
https://github.com/llvm/llvm-project/pull/92

Fix MSVC 1920+ auto NTTP mangling for pointers to members (#97007)

Fixes https://github.com/llvm/llvm-project/issues/70899.

This is a continuation of
https://github.com/llvm/llvm-project/pull/92477 for pointers to member
data and pointers to member functions.

The mangled name must be prefixed with `$M <mangled-type>` for the
deduced type of the nttp parameter.

show more ...

Fix MSVC Demangling with auto NTTP mangled names for function pointer, pointer to data and integral types (#96590)

As cited here, https://github.com/llvm/llvm-project/pull/92477, undname
needs upda

Fix MSVC Demangling with auto NTTP mangled names for function pointer, pointer to data and integral types (#96590)

As cited here, https://github.com/llvm/llvm-project/pull/92477, undname
needs updating to support the new auto NTTP name mangling.

In short the deduced type of the auto NTTP parameter is mangled as `$M
<type> <nttp-param>`. However the deduced type is not printed for the
undecorated name so the `$M <type>` is parsed but simply ignored when
stringifying the generated AST.

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

[MicrosoftDemangle] fix warn-trailing false positive

A follow up to commit 6bad76c7ae93 ("[Demangle] fix windows tests")
based on @thakis' report.

Fixes: #63740

Reviewed By: thakis

Differential R

[MicrosoftDemangle] fix warn-trailing false positive

A follow up to commit 6bad76c7ae93 ("[Demangle] fix windows tests")
based on @thakis' report.

Fixes: #63740

Reviewed By: thakis

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

show more ...

[Demangle] convert microsoftDemangle to take a std::string_view

This should be last of the "bottom-up conversions" of various demanglers
to accept std::string_view. After this, D149104 may be revis

[Demangle] convert microsoftDemangle to take a std::string_view

This should be last of the "bottom-up conversions" of various demanglers
to accept std::string_view. After this, D149104 may be revisited.

Reviewed By: MaskRay

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

show more ...

[Demangle] remove unused params of microsoftDemangle

No call sites use these parameters, so drop them.

Reviewed By: MaskRay

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

[Demangle] fix windows tests

My reland of https://reviews.llvm.org/D148546 has caused a few windows
demangler tests to fail when run with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON
on windows.

I have a snea

[Demangle] fix windows tests

My reland of https://reviews.llvm.org/D148546 has caused a few windows
demangler tests to fail when run with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON
on windows.

I have a sneaking suspicion that MSVC's
std::string_view::iterator::operator* may be missing a nullptr check.

Link: https://lab.llvm.org/buildbot/#/builders/42/builds/9723/steps/7/logs/stdio

Reviewed By: ayzhao

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

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

[StringView] remove consumeFront

Towards converting our use of llvm::StringView to std::string_view,
remove a method that std::string_view doesn't have.

This could be moved to the nascent llvm/ADT/

[StringView] remove consumeFront

Towards converting our use of llvm::StringView to std::string_view,
remove a method that std::string_view doesn't have.

This could be moved to the nascent llvm/ADT/StringViewExtras.h, but the
use is highly localized to one TU. Move this to be a static function
there.

Reviewed By: MaskRay

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

show more ...

[StringView] remove popFront

Towards converting our use of llvm::StringView to std::string_view,
remove a method that std::string_view doesn't have.

llvm::StringView::popFront is similar to std::st

[StringView] remove popFront

Towards converting our use of llvm::StringView to std::string_view,
remove a method that std::string_view doesn't have.

llvm::StringView::popFront is similar to std::string_view::remove_prefix
but with a reference to std::string_view::front taken first.

Reviewed By: MaskRay

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

show more ...

[StringView] remove ctor incompatible with std::string_view

Towards replacing llvm::StringView with std::string_view, remove ctor
that std::string_view doesn't have an analog for.

Reviewed By: eric

[StringView] remove ctor incompatible with std::string_view

Towards replacing llvm::StringView with std::string_view, remove ctor
that std::string_view doesn't have an analog for.

Reviewed By: erichkeane, MaskRay

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

show more ...

[StringView] remove dropFront

Towards converting our use of llvm::StringView to std::string_view,
remove a method that std::string_view doesn't have.
llvm::StringView::dropFront is semantically simi

[StringView] remove dropFront

Towards converting our use of llvm::StringView to std::string_view,
remove a method that std::string_view doesn't have.
llvm::StringView::dropFront is semantically similar to
std::string_view::substr but with the input clamped to the size. No code
was relying on clamping other than the rust demangler, which I fixed in
https://reviews.llvm.org/D148272. Removing this method makes it easier
to switch over code later.

Reviewed By: MaskRay

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

show more ...

[Demangle] Remove uses of llvm::itanium_demangle::StringView::{dropBack,dropFront}. NFC

Make it easier to migrate StringView to std::string_view.

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

[MicrosoftDemangle] Set error to true when returning nullptr.

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] Fix string copy confusion

The microsoft demangler makes copies of the demangled strings, but has
some confusion between StringView representation (sans NUL), and
C-strings (with NUL). Here w

[llvm] Fix string copy confusion

The microsoft demangler makes copies of the demangled strings, but has
some confusion between StringView representation (sans NUL), and
C-strings (with NUL). Here we also have a use of strcpy, which
happens to work because the incoming string view happens to have a
trailing NUL. But a simple memcpy excluding the NUL is sufficient.

Reviewed By: dblaikie, erichkeane

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

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