| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Build of shared library LLVMDemangle.so fails due to dependency problem.
llvm-svn: 333395
|
|
|
|
|
|
|
| |
After r333390 build of LLVMDemangle.so fails due to unresolved
reference `llvm::report_bad_alloc_error`.
llvm-svn: 333394
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 333390
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: erik.pilkington, ruiu, echristo, pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47248
llvm-svn: 333159
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
I'm committing this to libcxxabi too so that the two demanglers remain as
simular as possible.
llvm-svn: 329950
|
|
|
|
| |
llvm-svn: 329601
|
|
|
|
| |
llvm-svn: 329600
|
|
|
|
| |
llvm-svn: 329599
|
|
|
|
| |
llvm-svn: 328507
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Fixes PR33569.
llvm-svn: 328462
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts:
r328072 "Move Compiler.h from Support to Demangler to fix layering."
r328073 "Fix the actual user of DataTypes.h in llvm-c to avoid the circular dependency"
Failing bots:
http://green.lab.llvm.org/green/job/clang-stage2-coverage-R/
http://green.lab.llvm.org/green/job/clang-stage2-configure-Rlto/
llvm-svn: 328085
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 321114
|
|
|
|
|
|
| |
This is a port of libcxxabi's r304113.
llvm-svn: 304114
|
|
|
|
| |
llvm-svn: 304053
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This reverts commit r303375 since it didn't compile.
llvm-svn: 303377
|
|
|
|
| |
llvm-svn: 303375
|
|
|
|
| |
llvm-svn: 303365
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Found with ASAN + libFuzzer by Kostya Serebryany <kcc@google.com>
llvm-svn: 293330
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Rather than hard-coding magic values of 1, 2, 4 (bit-field), use an enum
to name the values. NFC.
llvm-svn: 292975
|
|
|
|
|
|
|
|
|
|
| |
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 could create a local typedef for std::vector called Vector. Inline the use
of std::vector rather than use the typedef. NFC.
llvm-svn: 287471
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Prefer direct member initialization over the explicit out-of-line initialization
for the construction of the local type. NFC.
llvm-svn: 287469
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 requires removing the custom allocator, since Demangle cannot
depend on Support and so cannot use Compiler.h.
llvm-svn: 280750
|
|
|
|
| |
llvm-svn: 280740
|
|
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
|