summaryrefslogtreecommitdiffstats
path: root/llvm/test/Demangle/ms-nested-scopes.test
Commit message (Collapse)AuthorAgeFilesLines
* llvm-undname: Tweak arena allocatorNico Weber2019-04-161-0/+3
| | | | | | | | | | | | | | | | - Make `allocUnalignedBuffer` look more like `allocArray` and `alloc`. No behavior change. - Change `Head->Used < Head->Capacity` to `Head->Used <= Head->Capacity` in `allocArray` and `alloc`. No intended behavior change, might be a minuscule memory usage improvement. Noticed this since it was the logic used in `allocUnalignedBuffer`. - Don't let `allocArray` alloc too small buffers for names that have more than 512 levels of nesting (in 64-bit builds). Fixes a heap buffer overflow found by oss-fuzz. Differential Revision: https://reviews.llvm.org/D60774 llvm-svn: 358489
* [MS Demangler] Print public:, protected:, private: if set in FunctionClass ↵Nico Weber2018-11-131-9/+9
| | | | | | | | | | | | or a variable's StorageClass. 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
* [MS Demangler] Demangle symbols in function scopes.Zachary Turner2018-07-301-0/+146
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 llvm-svn: 338226
OpenPOWER on IntegriCloud