Incidentally all allocations that we currently perform were
properly aligned, but this was only an accident.
Thanks to Erik Pilkington for catching this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337596 91177308-0d34-0410-b5e6-96231b3b80d8
This adds initial support for a demangling library (LLVMDemangle)
and tool (llvm-undname) for demangling Microsoft names. This
doesn't cover 100% of cases and there are some known limitations
which I intend to address in followup patches, at least until such
time that we have (near) 100% test coverage matching up with all
of the test cases in clang/test/CodeGenCXX/mangle-ms-*.
Differential Revision: https://reviews.llvm.org/D49552
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337584 91177308-0d34-0410-b5e6-96231b3b80d8
These are all methods that, while not currently used in the
Itanium demangler, are generally useful enough that it's
likely the itanium demangler could find a use for them. More
importantly, they are all necessary for the Microsoft demangler
which is up and coming in a subsequent patch. Rather than
combine these into a single monolithic patch, I think it makes
sense to commit this utility code first since it is very simple,
this way it won't detract from the substance of the MS demangler
patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337316 91177308-0d34-0410-b5e6-96231b3b80d8
In a followup I'm looking to add a Microsoft demangler. Doing
so needs a lot of the same utility classes and feature test
macros which are already implemented in ItaniumDemangle.cpp.
So move all of these things into header files so that they
can be re-used by a new demangler.
Differential Revision: https://reviews.llvm.org/D49399
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337217 91177308-0d34-0410-b5e6-96231b3b80d8
Code review feedback from r328123 prefers copying the few feature test
macros used by Demangle into there, rather than sinking the header into
an odd corner like Demangle.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333965 91177308-0d34-0410-b5e6-96231b3b80d8
After r333390 build of LLVMDemangle.so fails due to unresolved
reference `llvm::report_bad_alloc_error`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333394 91177308-0d34-0410-b5e6-96231b3b80d8
In r325551 many calls of malloc/calloc/realloc were replaces with calls of
their safe counterparts defined in the namespace llvm. There functions
generate crash if memory cannot be allocated, such behavior facilitates
handling of out of memory errors on Windows.
If the result of *alloc function were checked for success, the function was
not replaced with the safe variant. In these cases the calling function made
the error handling, like:
T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T)));
if (NewElts == nullptr)
report_bad_alloc_error("Allocation of SmallVector element failed.");
Actually knowledge about the function where OOM occurred is useless. Moreover
having a single entry point for OOM handling is convenient for investigation
of memory problems. This change removes custom OOM errors handling and
replaces them with calls to functions `llvm::safe_*alloc`.
Declarations of `safe_*alloc` are moved to a separate include file, to avoid
cyclic dependency in SmallVector.h
Differential Revision: https://reviews.llvm.org/D47440
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333390 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329951 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328464 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328463 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328123 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328072 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327859 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303738 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293643 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292976 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292965 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292573 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287472 91177308-0d34-0410-b5e6-96231b3b80d8
We could create a local typedef for std::vector called Vector. Inline the use
of std::vector rather than use the typedef. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287471 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287470 91177308-0d34-0410-b5e6-96231b3b80d8
Prefer direct member initialization over the explicit out-of-line initialization
for the construction of the local type. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287469 91177308-0d34-0410-b5e6-96231b3b80d8
