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.
What prohibits the string from being empty after this point?