This parses a mangled name into an AST (typically an intermediate stage in
itaniumDemangle) and provides some functions to query certain properties or
print certain parts of the demangled name.
Differential revision: https://reviews.llvm.org/D44668
llvm-svn: 329951
Strictly in a conversion operator's type, a <template-param> refers to a
<template-arg> that is further ahead in the mangled name. Instead of
doing a second parse to resolve these, introduce a
ForwardTemplateReference Node and back-patch the referenced
<template-arg> when we're in the right context.
This is also a correctness fix, previously we would only do a second
parse if the <template-param> was out of bounds in the current set of
<template-args>. This lead to misdemangles (gasp!) when the conversion
operator was a member of a templated struct, for instance.
llvm-svn: 328464
Rather than eagerly propagating up parameter pack sizes in Node ctors,
find the parameter pack size during printing. This is being done to
support back-patching forward referencing <template-param>s.
llvm-svn: 328463
Compiler.h is used by Demangle (which Support depends on) - so sink it
into Demangle to avoid a circular dependency
DataTypes.h is used by llvm-c (which Support depends on) - so sink it
into llvm-c.
DataTypes.h could probably be fixed the other way - making llvm-c depend
on Support instead of Support depending on llvm-c - if anyone feels
that's the better option, happy to work with them on that.
I /think/ this'll address the layering issues that previous attempts to
commit this have triggered in the Modules buildbot, but I haven't been
able to reproduce that build so can't say for sure. If anyone's having
trouble with this - it might be worth taking a look to see if there's a
quick fix/something small I missed rather than revert, but no worries.
llvm-svn: 328123
Support depends on Demangle (Support/Unix/Signals.inc), so Demangle
including Support/Compiler.h created a circular dependency.
Leave a forwarding shim of Compiler.h because it makes more sense for
users (a deeper fix might involve splitting Support into lower and upper
Support - but that also sounds a bit weird/awkward) than thinking about
the dependency on the Demangler.
llvm-svn: 328072
Some significant work has gone into libcxxabi's copy of this file:
- Uses an AST to represent mangled names.
- Support/bugfixes for many C++ features.
- Uses LLVM coding style.
llvm-svn: 327859
Previously if we parsed a constructor then we set parsed_ctor_dtor_cv
to true and never reseted it. This causes issue when a template argument
references a constructor (e.g. type of lambda defined inside a
constructor) as we will have the parsed_ctor_dtor_cv flag set what will
cause issues when parsing later arguments.
Differential Revision: https://reviews.llvm.org/D33385
libcxxabi change: https://reviews.llvm.org/rL303737
llvm-svn: 303738
In clang, the grammar for mangling for these names are "<special-name> ::= TW <object name>" for wrapper variables or "<special-name> ::= TH <object name>" for initialization variables.
Initial change was made in libccxxabi r293638
llvm-svn: 293643
When demangling a CV-qualified function type with a final reference type
parameter, we would treat the reference type parameter as a r-value ref
accidentally. This would result in the improper decoration of the
function type itself.
Resolves PR31741!
llvm-svn: 292976
When demangling a CV-qualified function type with a final parameter with
a reference type, we would insert the CV qualification on the parameter
rather than the function, and in the process adjust the insertion point
by one extra, splitting the type name. This avoids doing so, even
though the attribution is still incorrect.
llvm-svn: 292965
This reverts SVN r286795. This was incorrect the demangler is expected
to be able to demangle types as well as functions. This makes the
behaviour of itaniumDemangle similar to __cxa_demangle once more.
llvm-svn: 292573
The demangler had stopped using a custom allocator but had not been updated to
remove the use of the explicit allocator passing. This removes that as we do
not need to do anything special here anymore. This just makes the code more
compact. NFC.
llvm-svn: 287472
We created a local typedef for `std::basic_string<char, std::char_traits<char>>`
which is just `std::string`. Remove the local typedef and propagate the type
information through the rest of the demangler. NFC.
llvm-svn: 287470
Only attempt to demangle symbols which have the itanium C++ prefix of `_Z`.
This ensures that we do not treat any symbol name as a managled named. We would
previously treat a C function `f` as a mangled name and decode that to `float`
incorrectly.
While it is easy to add tests for this, Mehdi recommended against introducing
tests for the demangler as libc++abi should cover the testing.
llvm-svn: 286795
This adds a copy of the demangler in libcxxabi.
The code also has no dependencies on anything else in LLVM. To enforce
that I added it as another library. That way a BUILD_SHARED_LIBS will
fail if anyone adds an use of StringRef for example.
The no llvm dependency combined with the fact that this has to build
on linux, OS X and Windows required a few changes to the code. In
particular:
No constexpr.
No alignas
On OS X at least this library has only one global symbol:
__ZN4llvm16itanium_demangleEPKcPcPmPi
My current plan is:
Commit something like this
Change lld to use it
Change lldb to use it as the fallback
Add a few #ifdefs so that exactly the same file can be used in
libcxxabi to export abi::__cxa_demangle.
Once the fast demangler in lldb can handle any names this
implementation can be replaced with it and we will have the one true
demangler.
llvm-svn: 280732
Erik Pilkington