There are a couple of issues you run into when you start getting into
more complex names, especially with regards to function local statics.
When you've got something like:
int x() {
static int n = 0;
return n;
}
Then this needs to demangle to something like
int `int __cdecl x()'::`1'::n
The nested mangled symbols (e.g. `int __cdecl x()` in the above
example) also share state with regards to back-referencing, so
we need to be able to re-use the demangler in the middle of
demangling a symbol while sharing back-ref state.
To make matters more complicated, there are a lot of ambiguities
when demangling a symbol's qualified name, because a function local
scope pattern (usually something like `?1??name?`) looks suspiciously
like many other possible things that can occur, such as `?1` meaning
the second back-ref and disambiguating these cases is rather
interesting. The `?1?` in a local scope pattern is actually a special
case of the more general pattern of `? + <encoded number> + ?`, where
"encoded number" can itself have embedded `@` symbols, which is a
common delimeter in mangled names. So we have to take care during the
disambiguation, which is the reason for the overly complicated
`isLocalScopePattern` function in this patch.
I've added some pretty obnoxious tests to exercise all of this, which
exposed several other problems related to back-referencing, so those
are fixed here as well. Finally, I've uncommented some tests that were
previously marked as `FIXME`, since now these work.
Differential Revision: https://reviews.llvm.org/D49965
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338226 91177308-0d34-0410-b5e6-96231b3b80d8
We need to be able to initiate a nested demangling from inside
of an "outer" demangling. These need to be able to share some
state, such as back-references. As a result, we can't store
things like the output stream or the mangled name in the Demangler
class, since each demangling will have different values. So
remove this state and pass it through the necessary methods.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338219 91177308-0d34-0410-b5e6-96231b3b80d8
There are some very subtle differences between how one should
parse symbol names and type names. They differ with respect
to back-referencing, the set of legal values that can appear
as the unqualified portion, and various other aspects.
By separating the parsing code into separate paths, we can
remove a lot of ambiguity during the demangling process, which
is necessary for demangling more complicated things like
function local statics, nested classes, and lambdas.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338207 91177308-0d34-0410-b5e6-96231b3b80d8
Properly demangle function parameter back-references.
Previously we treated lists of function parameters and template
parameters the same. There are some important differences with regards
to back-references, and some less important differences regarding which
characters can appear before or after the name.
The important differences are that with a given type T, all instances of
a function parameter list share the same global back-ref table.
Specifically, if X and Y are function pointers, then there are 3
entities in the declaration X func(Y) which all affect and are affected
by the master parameter back-ref table:
1) The parameter list of X's function type
2) the parameter list of func itself
3) The parameter list of Y's function type.
The previous code would create a back-reference table that was local to
a single parameter list, so it would not be shared across parameter
lists.
This was discovered when porting ms-back-references.test from clang's
mangling tests. All of these tests should now pass with the new changes.
In doing so, I split the function for parsing template and function
parameters into two separate functions. This makes the template
parameter list parsing code in particular very small and easy to
understand now.
Differential Revision: https://reviews.llvm.org/D49875
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338075 91177308-0d34-0410-b5e6-96231b3b80d8
For function pointers, we would print something like
int __cdecl (*)(int)
We need to move the calling convention inside, and print
int (__cdecl *)(int)
This patch implements this change for regular function pointers as
well as member function pointers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338068 91177308-0d34-0410-b5e6-96231b3b80d8
This converts the arg qualifier mangling tests from
clang/CodeGenCXX/mangle-ms-arg-qualifiers.cpp to demangling tests.
Most tests already pass, so this patch doesn't come with any
functional change, just the addition of new tests. The few tests
that don't pass are left in with a FIXME label so that they don't
run but serve as documentation about what still doesn't work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338067 91177308-0d34-0410-b5e6-96231b3b80d8
After this patch, we can now properly demangle pointers to member
functions. The calling convention is located in the wrong place,
but this will be fixed in a followup since it also affects non
member function pointers.
Differential Revision: https://reviews.llvm.org/D49639
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338065 91177308-0d34-0410-b5e6-96231b3b80d8
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
