- 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
- 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
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
Demangler::parse() for MD5 names would:
1. Put all remaining text into the MD5 name sight unseen
2. Not modify MangledName
This meant that if the demangler recursively called parse() (e.g. in
demangleLocallyScopedNamePiece()), every recursive call that started on
an MD5 name would add all remaining bytes to the output buffer but
only advance the input by a byte. For valid inputs, MD5 types are
never (well, see comments for 2 exceptions) nested, but for invalid
input this could cause memory use quadratic in the input size.
llvm-svn: 361744
If a template parameter refers to a pointer to member, but the mangling
of that was a string literal instead of a real symbol, llvm-undname used
to crash instead of rejecting the input.
llvm-svn: 361402
llvm-undname used to put '\x' in front of every pair of nibbles, but
u"\xD7\xFF" produces a string with 6 bytes: \xD7 \0 \xFF \0 (and \0\0). Correct
for a single character (plus terminating \0) is u\xD7FF instead.
Now, wchar_t, char16_t, and char32_t strings roundtrip from source to
clang-cl (and cl.exe) and then llvm-undname.
(...at least as long as it's not a string like L"\xD7FF" L"foo" which
gets demangled as L"\xD7FFfoo", where the compiler then considers the
"f" as part of the hex escape. That seems ok.)
Also add a comment saying that the "almost-valid" char32_t string I
added in my last commit is actually produced by compilers.
llvm-svn: 358857
If a unsigned with all 4 bytes non-0 was passed to outputHex(), there
were two off-by-ones in it:
- Both MaxPos and Pos left space for the final \0, which left the buffer
one byte to small. Set MaxPos to 16 instead of 15 to fix.
- The `assert(Pos >= 0);` was after a `Pos--`, move it up one line.
Since valid Unicode codepoints are <= 0x10ffff, this could never really
happen in practice.
Found by oss-fuzz.
llvm-svn: 358856
- Don't assert when a string looks like a u32 string to the heuristic
but doesn't have a length that's 0 mod 4. Instead, classify those
as u16 with embedded \0 chars. Found by oss-fuzz.
- Print embedded nul bytes as \0 instead of \x00.
llvm-svn: 358835
Similar to r358421: A StructorIndentifierNode has a Class field which
is read when printing it, but if the StructorIndentifierNode appears in
a template argument then demangleFullyQualifiedSymbolName() which sets
Class isn't called. Since StructorIndentifierNodes are always leaf
names, we can just reject them as well.
Found by oss-fuzz.
llvm-svn: 358491
A ConversionOperatorIdentifierNode has a TargetType which is read when
printing it, but if the ConversionOperatorIdentifierNode appears in a
template argument there's nothing that can provide the TargetType.
Normally the COIN is a symbol (leaf) name and takes its TargetType from the
symbol's type, but in a template argument context the COIN can only be
either a non-leaf name piece or a type, and must hence be invalid.
Similar to the COIN check in demangleDeclarator().
Found by oss-fuzz.
llvm-svn: 358421
This fixes a regression from https://reviews.llvm.org/D60354. We used to
SymbolNode *Symbol = demangleEncodedSymbol(MangledName, QN);
if (Symbol) {
Symbol->Name = QN;
}
but changed that to
SymbolNode *Symbol = demangleEncodedSymbol(MangledName, QN);
if (Error)
return nullptr;
Symbol->Name = QN;
and one branch somewhere returned a nullptr without setting Error.
Looking at the code changed in r340083 and r340710 that branch looks
like a remnant from an earlier attempt to demangle RTTI descriptors
that has since been rewritten -- so just remove this branch. It
shouldn't change behavior for correctly mangled symbols.
llvm-svn: 358112
For functions whose callers don't check that enough input is present,
add checks at the start of the function that enough input is there and
set Error otherwise.
For functions that return AST objects, return nullptr instead of
incomplete AST objects with nullptr fields if an error occurred during
the function.
Introduce a new function demangleDeclarator() for the sequence
demangleFullyQualifiedSymbolName(); demangleEncodedSymbol() and
use it in the two places that had this sequence. Let this new function
check that ConversionOperatorIdentifiers have a valid TargetType.
Some of the bad inputs found by oss-fuzz, others by inspection.
Differential Revision: https://reviews.llvm.org/D60354
llvm-svn: 357936
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This is a follow-up to r351448. It adds support for other _*Z extensions
of the Itanium demanling, to the newly available demangle function
heuristic.
Reviewed by: erik.pilkington, rupprecht, grimar
Differential Revision: https://reviews.llvm.org/D56855
llvm-svn: 351551
With this patch, the copies of the files ItaniumDemangle.h,
StringView.h, and Utility.h are kept byte-for-byte in sync between
libcxxabi and llvm. All differences (namespaces, fallthrough, and
unreachable macros) are defined in each copies' DemanglerConfig.h.
This patch also adds a script to copy changes from libcxxabi
(cp-to-llvm.sh), and a README.txt explaining the situation.
Differential revision: https://reviews.llvm.org/D53538
llvm-svn: 351474
This allows it to be used in an upcoming llvm-readobj change.
A small change in internal behaviour of the function is to always call
the microsoftDemangle function if the string does not have an itanium
encoding prefix, rather than only if it starts with '?'. This is
harmless because the microsoftDemangle function does the same check
already.
Reviewed by: grimar, erik.pilkington
Differential Revision: https://reviews.llvm.org/D56721
llvm-svn: 351448
Starting in C++17, MSVC introduced a new mangling for function
parameters that are themselves noexcept functions. This patch
makes llvm-undname properly demangle them.
Patch by Zachary Henkel
Differential Revision: https://reviews.llvm.org/D55769
llvm-svn: 350656
Sometimes it's useful to be able to output demangled names without
tag specifiers like "struct", "class", etc. This patch adds a
flag enabling this.
llvm-svn: 350241
Once we detect a 'P', we know we a pointer type is upcoming, so
we make some assumptions about the output that follows. If those
assumptions didn't hold, we would assert. Instead, we should
fail gracefully and propagate the error up.
llvm-svn: 349169
Summary:
This (very specialized) function was added to enable an LLDB use case.
Now that a more generic interface (overriding of parser functions -
D52992) is available, and LLDB has been converted to use that (D54074),
the function is unused and can be removed.
Reviewers: erik.pilkington, sgraenitz, rsmith
Subscribers: mgorny, hiraditya, christof, libcxx-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D54893
llvm-svn: 347670
undname prints them, and the information is in the decorated name, so we probably shouldn't lose it when undecorating.
I spot-checked a few of the funnier-looking outputs, and undname has the same output.
Differential Revision: https://reviews.llvm.org/D54396
llvm-svn: 346791
This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.
We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.
I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.
Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu
Differential Revision: https://reviews.llvm.org/D53950
llvm-svn: 345882
Summary:
The original commit message was:
This uses CRTP (for performance reasons) to allow a user the override
demangler functions to implement custom parsing logic. The motivation
for this is LLDB, which needs to occasionaly modify the mangled names.
One such instance is already implemented via the TypeCallback member,
but this is very specific functionality which does not help with any
other use case. Currently we have a use case for modifying the
constructor flavours, which would require adding another callback. This
approach does not scale.
With CRTP, the user (LLDB) can override any function it needs without
any special support from the demangler library. After LLDB is ported to
use this instead of the TypeCallback mechanism, the callback can be
removed.
The only difference here is the addition of a unit test which exercises
the CRTP mechanism to override a function in the parser.
Reviewers: erik.pilkington, rsmith, EricWF
Subscribers: mgorny, kristina, llvm-commits
Differential Revision: https://reviews.llvm.org/D53300
llvm-svn: 344703
* Use same method of initializing the output stream and its buffer
* Allow a nullptr Status pointer
* Don't print the mangled name on demangling error
* Write to N (if it is non-nullptr)
Differential Revision: https://reviews.llvm.org/D52104
llvm-svn: 342330
$$Z appears between adjacent expanded parameter packs in the
same template instantiation. We don't need to print it, it's
only there to disambiguate between manglings that would otherwise
be ambiguous. So we just need to parse it and throw it away.
llvm-svn: 341119
These bugs were found by writing a Python script which spidered
the entire Chromium build directory tree demangling every symbol
in every object file. At the start, the tool printed:
Processed 27443 object files.
2926377/2936108 symbols successfully demangled (99.6686%)
9731 symbols could not be demangled (0.3314%)
14589 files crashed while demangling (53.1611%)
After this patch, it prints:
Processed 27443 object files.
41295518/41295617 symbols successfully demangled (99.9998%)
99 symbols could not be demangled (0.0002%)
0 files crashed while demangling (0.0000%)
The issues fixed in this patch are:
* Ignore empty parameter packs. Previously we would encounter
a mangling for an empty parameter pack and add a null node
to the AST. Since we don't print these anyway, we now just
don't add anything to the AST and ignore it entirely. This
fixes some of the crashes.
* Account for "incorrect" string literal demanglings. Apparently
an older version of clang would not truncate mangled string
literals to 32 bytes of encoded character data. The demangling
code however would allocate a 32 byte buffer thinking that it
would not encounter more than this, and overrun the buffer.
We now demangle up to 128 bytes of data, since the buggy
clang would encode up to 32 *characters* of data.
* Extended support for demangling init-fini stubs. If you had
something like
struct Foo {
static vector<string> S;
};
this would generate a dynamic atexit initializer *for the
variable*. We didn't handle this, but now we print something
nice. This is actually an improvement over undname, which will
fail to demangle this at all.
* Fixed one case of static this adjustment. We weren't handling
several thunk codes so we didn't recognize the mangling. These
are now handled.
* Fixed a back-referencing problem. Member pointer templates
should have their components considered for back-referencing
The remaining 99 symbols which can't be demangled are all symbols
which are compiler-generated and undname can't demangle either.
llvm-svn: 341000
Mostly this includes <auto> and <decltype-auto> return values.
Additionally, this fixes a fairly obscure back-referencing bug
that was encountered in one of the C++14 tests, which is that
if you have something like Foo<&bar, &bar> then the `bar`
forms a backreference.
llvm-svn: 340896
Previously we had a FunctionSigFlags, but it's more flexible
to just have one set of output flags that apply to the entire
process and just pipe the entire set of flags through the
output process.
This will be useful when we start allowing the user to customize
the outputting behavior.
llvm-svn: 340894
This is a pretty large refactor / re-write of the Microsoft
demangler. The previous one was a little hackish because it
evolved as I was learning about all the various edge cases,
exceptions, etc. It didn't have a proper AST and so there was
lots of custom handling of things that should have been much
more clean.
Taking what was learned from that experience, it's now
re-written with a completely redesigned and much more sensible
AST. It's probably still not perfect, but at least it's
comprehensible now to someone else who wants to come along
and make some modifications or read the code.
Incidentally, this fixed a couple of bugs, so I've enabled
the tests which now pass.
llvm-svn: 340710
Previously if you had something like this:
template<typename T>
struct Foo {
template<typename U>
Foo(U);
};
Foo F(3.7);
this would mangle as ??$?0N@?$Foo@H@@QEAA@N@Z
and this would be demangled as:
undname: __cdecl Foo<int>::Foo<int><double>(double)
llvm-undname: __cdecl Foo<int>::Foo<int>(double)
Note the lack of the constructor template parameter in our
demangling.
This patch makes it so we print the constructor argument list.
llvm-svn: 340356
I found these by running llvm-undname over a couple hundred
megabytes of object files generated as part of building chromium.
The issues fixed in this patch are:
1) decltype-auto return types.
2) Indirect vtables (e.g. const A::`vftable'{for `B'})
3) Pointers, references, and rvalue-references to member pointers.
I have exactly one remaining symbol out of a few hundred MB of object
files that produces a name we can't demangle, and it's related to
back-referencing.
llvm-svn: 340341
This is encoded as __E and should print something like
"dynamic initializer for 'Foo'(void)"
This also adds support for dynamic atexit destructor, which is
basically identical but encoded as __F with slightly different
description.
llvm-svn: 340239
Summary:
This transforms the Itanium demangler into a generic reusable library that can
be used to build, traverse, and transform Itanium mangled name trees.
This is in preparation for adding a canonicalizing demangler, which
cannot live in the Demangle library for layering reasons. In order to
keep the diffs simpler, this patch moves more code to the new header
than is strictly necessary: in particular, all of the printLeft /
printRight implementations can be moved to the implementation file.
(And indeed we could make them non-virtual now if we wished, and remove
the vptr from Node.)
All nodes are now included in the Kind enumeration, rather than omitting
some of the Expr nodes, and the three different floating-point literal
node types now have distinct Kind values.
As a proof of concept for the visitation / matching mechanism, this
patch implements a Node dumping facility on top of it, replacing the
prior mechanism that produced the pretty-printed output rather than a
tree dump. Sample dump output:
FunctionEncoding(
NameType("int"),
NameWithTemplateArgs(
NestedName(
NameWithTemplateArgs(
NameType("A"),
TemplateArgs(
{NameType("B")})),
NameType("f")),
TemplateArgs(
{NameType("int")})),
{},
<null>,
QualConst, FunctionRefQual::FrefQualLValue)
As a next step, it would make sense to move the LLVM high-level interface to
the demangler (the itaniumDemangler function and ItaniumPartialDemangler class)
into the Support library, and implement them in terms of the Demangle library.
This would allow the libc++abi demangler implementation to be an identical copy
of the llvm Demangle library, and would allow the LLVM implementation to reuse
LLVM components such as llvm::BumpPtrAllocator, but we'll need to decide how to
coordinate that with the MS ABI demangler, so I'm not doing that in this patch.
No functionality change intended other than the behavior of dump().
Reviewers: erik.pilkington, zturner, chandlerc, dlj
Subscribers: aheejin, llvm-commits
Differential Revision: https://reviews.llvm.org/D50930
llvm-svn: 340203
A while back I submitted a patch to resolve backreferences
lazily, thinking this that it was not always possible to know
in advance what type you were looking at until you had completed
a full pass over the input, and therefore it would be impossible
to resolve backreferences eagerly.
This was mistaken though, and turned out to be an unrelated
problem. In fact, the reverse is true. You *must* resolve
backreferences eagerly. This is because certain types of nested
mangled symbols do not share a backreference context with their
parent symbol, and as such, if you try to resolve them lazily
their backreference context will have been lost by the time you
finish demangling the entire input. On the other hand, resolving
them eagerly appears to always work, and enables us to port
many more tests over.
llvm-svn: 340126
We were only printing the vtordisp thunk before as the previous
patch was more aimed at getting special operators working, one
of which was a thunk. This patch gets all thunk types to print
properly, and adds a test for each one.
llvm-svn: 340088
Previously, some of the code for actually parsing mangled
operator names was more like formatting code in nature,
and was interspersed with the demangling code which builds
the AST. This means that by the time we got to the printing
code, we had lost all information about what type of operator
we had, and all we were left with was a string that we just
had to print. However, not all operators are actually even
operators. it's basically just a catch-all mangling for
"special names", and for some of the other types it helps
to know when we're actually doing the printing what it is.
This patch changes the way things work by introducing an
OperatorInfo structure and corresponding enumeration. When
we demangle we store the enumeration value and demangled
components separately. This gives more flexibility during
printing.
In doing so, some demanglings of special names which we didn't
previously support come out of this for free, so we now demangle
those.
A few are more complex and are better left for a followup patch
though.
An exhaustive test of every possible operator code is included,
with the ones that don't yet work commented out.
llvm-svn: 340046
When demangling string literals, Microsoft's undname
simply prints 'string'. This patch implements string
literal demangling while doing a bit better than this
by decoding as much of the string as possible and
trying to faithfully reproduce the original string
literal definition.
This is a bit tricky because the different character
types char, char16_t, and char32_t are not uniquely
identified by the mangling, so we have to use a
heuristic to try to guess the character type. But
it works pretty well, and many tests are added to
illustrate the behavior.
Differential Revision: https://reviews.llvm.org/D50806
llvm-svn: 339892
When we have an MD5 mangled name, we shouldn't choke and say
that it's an invalid name. Even though it's impossible to demangle,
we should just output the original name.
llvm-svn: 339891
1) We print __restrict twice on member pointers. This is fixed
and relevant tests are re-enabled.
2) Several tests were disabled because of printing slightly
different output than undname. These were confirmed to be
bugs in undname, so we just re-enable the tests.
3) The test for printing reference temporaries is re-enabled. This
is a clang mangling extension, so we have some flexibility with
how we demangle it. The output currently looks fine, so we just
re-enable the test with no fixes.
llvm-svn: 339708
This function calls a callback whenever a <type> is parsed.
This is necessary to implement FindAlternateFunctionManglings in LLDB, which
uses a similar hack in FastDemangle. Once that function has been updated to use
this version, FastDemangle can finally be removed.
Differential revision: https://reviews.llvm.org/D50586
llvm-svn: 339580
There are two cases we need to support with extern "C"
functions. The first is the case of a '9' indicating that
the function has no prototype. This occurs when we mangle
a symbol inside of an extern "C" function, but not the
function itself.
The second case is when we have an overloaded extern "C"
functions. In this case we emit $$J0 to indicate this.
This patch adds support for both of these cases.
llvm-svn: 339471
Before we wouldn't properly demangle something like
Foo<const int>. Template args have a special escape sequence
'$$C' that is optional, but if it is present contains
qualifiers. So we need to check for this and only if it
present, demangle qualifiers before demangling the type.
With this fix, we re-enable some tests that were previously
marked FIXME.
llvm-svn: 339465
These were uncovered when porting the mangling tests in
ms-templates.cpp from clang/CodeGenCXX over to demangling
tests. The main issues fixed here are surrounding integer
literal signed and unsignedness, empty array dimensions,
and pointer and reference non-type template parameters.
Differential Revision: https://reviews.llvm.org/D50512
llvm-svn: 339434
Template manglings use a fresh back-referencing context, so we
need to do the same. This fixes several existing tests which are
marked as FIXME, so those are now actually run.
llvm-svn: 339275
Function template names are not stored in the backref table,
but non-template function names are. The general pattern seems
to be that when you are demangling a symbol name, if the name
starts with '?' it does not go into the backreference table,
otherwise it does. Note that this even handles the general case
of operator names (template or otherwise) not going into the
back-reference table, anonymous namespaces not going into the
backreference table, etc.
It's important that we apply this check *only* for the
unqualified portion of a name, and only for symbol names.
For example, this does not apply to type names (such as class
templates) and we need to make sure that these still do go
into the backref table.
Differential Revision: https://reviews.llvm.org/D50394
llvm-svn: 339211
We need to both record and resolve back-references lazily due to
not being able to know until a demangling is complete whether or
not a name should go into the back-reference table.. This patch
implements lazy resolution of back-references, but we still have
eager recording of back-references. This will be fixed in a
subsequent patch.
llvm-svn: 338736
It seems like perhaps because cstdio isn't directly included, the
compiler is accidentally picking up wprintf from somewhere else
and trying to call that. Hopefully this fixes it.
llvm-svn: 338614