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

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

Demangle: correct swift_async demangling for Microsoft scheme

The emission was corrected for the swift_async calling convention but
the demangling support was not. This repairs the demangling suppo

Demangle: correct swift_async demangling for Microsoft scheme

The emission was corrected for the swift_async calling convention but
the demangling support was not. This repairs the demangling support as
well.

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

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

Give microsoftDemangle() an outparam for how many input bytes were consumed.

Demangling Itanium symbols either consumes the whole input or fails,
but Microsoft symbols can be successfully demangled

Give microsoftDemangle() an outparam for how many input bytes were consumed.

Demangling Itanium symbols either consumes the whole input or fails,
but Microsoft symbols can be successfully demangled with just some
of the input.

Add an outparam that enables clients to know how much of the input was
consumed, and use this flag to give llvm-undname an opt-in warning
on partially consumed symbols.

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

show more ...

Revert "Add some missing includes to MicrosoftDemangle.cpp (PR44217)"

This reverts commit 9b962d83ece841e43fd2823375dc6ddc94c1b178.

This didn't address the underlying issue (in MicrosoftDemangleNod

Revert "Add some missing includes to MicrosoftDemangle.cpp (PR44217)"

This reverts commit 9b962d83ece841e43fd2823375dc6ddc94c1b178.

This didn't address the underlying issue (in MicrosoftDemangleNodes.h)
that was fixed 6 months ago anyway.

show more ...

Add some missing includes to MicrosoftDemangle.cpp (PR44217)

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

Fix uninitialized variable warning. NFCI.

llvm-svn: 373450

llvm-undname: Add support for demangling typeinfo names

typeinfo names aren't symbols but string constant contents
stored in compiler-generated typeinfo objects, but llvm-cxxfilt
can demangle these

llvm-undname: Add support for demangling typeinfo names

typeinfo names aren't symbols but string constant contents
stored in compiler-generated typeinfo objects, but llvm-cxxfilt
can demangle these for Itanium names.

In the MSVC ABI, these are just a '.' followed by a mangled
type -- this means they don't start with '?' like all MS-mangled
symbols do.

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

llvm-svn: 372602

show more ...

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: More coverage-related cleanups

- The loop in demangleFunctionParameterList() only exits
on Error, @, and Z. All 3 cases were handled, so the
rest of the function is DEMANGLE_UNREAC

llvm-undname: More coverage-related cleanups

- The loop in demangleFunctionParameterList() only exits
on Error, @, and Z. All 3 cases were handled, so the
rest of the function is DEMANGLE_UNREACHABLE.

- The loop in demangleTemplateParameterList() always returns
on Error, so there's no need to check for that in the loop
header and after the loop.

- Add test cases for invalid function parameter manglings.

- Add a (redundant) test case for a simple template parameter
list mangling.

- Add a test case pointing out that varargs functions aren't
demangled correctly.

llvm-svn: 362540

show more ...

llvm-undname: Add test coverage for demangleInitFiniStub()

llvm-svn: 362536

llvm-undname: Yet more coverage for error paths

- For error returns in demangleSpecialTableNode(),
demangleLocalStaticGuard(), RTTITypeDescriptor,
demangleRttiBaseClassDescriptorNode(), demangle

llvm-undname: Yet more coverage for error paths

- For error returns in demangleSpecialTableNode(),
demangleLocalStaticGuard(), RTTITypeDescriptor,
demangleRttiBaseClassDescriptorNode(), demangleUnsigned(),
demangleUntypedVariable() (via RttiBaseClassArray)

- For ?_A and ?_P which are handled at early levels of the
demangler but are not implemented in a later stage; this
is now more obvious

- Replace a "default:" with an explicit list of cases, to
get -Wswitch check we list all cases

llvm-svn: 362520

show more ...

llvm-undname: More no-op changes to increase test coverage

- Add test coverage around invalid anon namespaces and
for error paths in demanglePrimitiveType() and in
demangleFullyQualifiedTypeName

llvm-undname: More no-op changes to increase test coverage

- Add test coverage around invalid anon namespaces and
for error paths in demanglePrimitiveType() and in
demangleFullyQualifiedTypeName()

- Use DEMANGLE_UNREACHABLE in two more unreachable places

llvm-svn: 362514

show more ...

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; Add more test coverage for demangleFunctionClass()

Also add two FC_Far that seem to be missing, by symmetry from
the public and protected cases. (But FC_Far isn't really a thing
anymor

llvm-undname; Add more test coverage for demangleFunctionClass()

Also add two FC_Far that seem to be missing, by symmetry from
the public and protected cases. (But FC_Far isn't really a thing
anymore, so this doesn't really have an observable effect.)

llvm-svn: 362344

show more ...

Remove code path that's dead after r358835

llvm-svn: 362333

llvm-undname: Support demangling char8_t

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

llvm-svn: 361839