summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Demangle
Commit message (Collapse)AuthorAgeFilesLines
* Resubmit r338340 "[MS Demangler] Better demangling of template arguments."Zachary Turner2018-07-311-45/+87
| | | | | | This broke the build with GCC, but has since been fixed. llvm-svn: 338403
* Revert r338340 "[MS Demangler] Better demangling of template arguments."Reid Kleckner2018-07-311-87/+46
| | | | | | Breaks the build with GCC, apparently. llvm-svn: 338344
* [MS Demangler] Better demangling of template arguments.Zachary Turner2018-07-311-46/+87
| | | | | | | | | | | This patch fixes demangling of template aliases as template-template arguments, and also fixes function pointers and references as not type template parameters. All of these can be properly demangled now, so I've ported over the test clang/test/CodeGenCXX/ms-template-callbacks.cpp. All of these tests pass llvm-svn: 338340
* [MS Demangler] Add rudimentary C++11 SupportZachary Turner2018-07-301-48/+173
| | | | | | | | | | | | | | This patch adds support for demangling r-value references, new operators such as the ""_foo operator, lambdas, alias types, nullptr_t, and various other C++11'isms. There is 1 failing test remaining in this file, which appears to be related to back-referencing. This type of problem has the potential to get ugly so I'd rather fix it in a separate patch. Differential Revision: https://reviews.llvm.org/D50013 llvm-svn: 338324
* Try to fix build.Zachary Turner2018-07-301-5/+5
| | | | llvm-svn: 338227
* [MS Demangler] Demangle symbols in function scopes.Zachary Turner2018-07-302-12/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [MS Demangler] NFC - Remove state from Demangler class.Zachary Turner2018-07-291-152/+152
| | | | | | | | | | | 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. llvm-svn: 338219
* [MS Demangler] Refactor some of the name parsing code.Zachary Turner2018-07-281-181/+246
| | | | | | | | | | | | | | 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. llvm-svn: 338207
* [demangler] Fix an oss-fuzz bug from r338138Erik Pilkington2018-07-281-0/+8
| | | | | | | | Stack overflow on invalid. While collapsing references, we were skipping over a cycle check in ForwardTemplateReference leading to a stack overflow. This commit fixes the problem by duplicating the cycle check in ReferenceType. llvm-svn: 338190
* [demangler] Support for reference collapsingErik Pilkington2018-07-271-46/+56
| | | | | | llvm.org/PR38323 llvm-svn: 338138
* Fix -Wsign-compare warning.Zachary Turner2018-07-261-1/+1
| | | | llvm-svn: 338078
* [MS Demangler] Properly handle function parameter back-refs.Zachary Turner2018-07-261-17/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 338075
* [MS Demangler] Print calling convention inside parentheses.Zachary Turner2018-07-261-35/+48
| | | | | | | | | | | | | | | 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. llvm-svn: 338068
* [MS Demangler] Add ms-arg-qualifiers.testZachary Turner2018-07-261-2/+5
| | | | | | | | | | | 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. llvm-svn: 338067
* [MS Demangler] Demangle pointers to member functions.Zachary Turner2018-07-262-46/+92
| | | | | | | | | | | 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 llvm-svn: 338065
* [MS Demangler] Demangle data member pointers.Zachary Turner2018-07-261-155/+191
| | | | | | Differential Revision: https://reviews.llvm.org/D49630 llvm-svn: 338061
* [demangler] call terminate() if allocation failedErik Pilkington2018-07-232-4/+17
| | | | | | | | | | We really should set *status to memory_alloc_failure, but we need to refactor the demangler a bit to properly propagate the failure up the stack. Until then, its better to explicitly terminate then rely on a null dereference crash. rdar://31240372 llvm-svn: 337759
* [Demangle] Attempt to fix arena memory leakReid Kleckner2018-07-231-1/+3
| | | | llvm-svn: 337720
* Remove a superfluous semicolonMartin Storsjo2018-07-201-1/+1
| | | | llvm-svn: 337599
* [Demangler] Correctly factor in assignment when allocating.Zachary Turner2018-07-201-24/+29
| | | | | | | | | Incidentally all allocations that we currently perform were properly aligned, but this was only an accident. Thanks to Erik Pilkington for catching this. llvm-svn: 337596
* [Demangler] Add missing overridesBenjamin Kramer2018-07-201-3/+3
| | | | | | -Winconsistent-missing-override complains about this. llvm-svn: 337592
* Fix a few warnings and style issues in MS demangler.Zachary Turner2018-07-201-17/+24
| | | | | | Also remove a broken test case. llvm-svn: 337591
* Add a Microsoft Demangler.Zachary Turner2018-07-202-1/+1535
| | | | | | | | | | | | | 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 llvm-svn: 337584
* [Demangle] Add missing header filesFangrui Song2018-07-171-0/+2
| | | | llvm-svn: 337318
* Add missing include.Zachary Turner2018-07-171-1/+2
| | | | llvm-svn: 337317
* Add some helper functions to the demangle utility classes.Zachary Turner2018-07-173-16/+128
| | | | | | | | | | | | | | These are all methods that, while not currently used in the Itanium demangler, are generally useful enough that it's likely the itanium demangler could find a use for them. More importantly, they are all necessary for the Microsoft demangler which is up and coming in a subsequent patch. Rather than combine these into a single monolithic patch, I think it makes sense to commit this utility code first since it is very simple, this way it won't detract from the substance of the MS demangler patch. llvm-svn: 337316
* Add missing includes.Zachary Turner2018-07-161-0/+2
| | | | llvm-svn: 337218
* [LLVMDemangle] Move some utility classes to header files.Zachary Turner2018-07-165-198/+257
| | | | | | | | | | | | In a followup I'm looking to add a Microsoft demangler. Doing so needs a lot of the same utility classes and feature test macros which are already implemented in ItaniumDemangle.cpp. So move all of these things into header files so that they can be re-used by a new demangler. Differential Revision: https://reviews.llvm.org/D49399 llvm-svn: 337217
* [demangler] Avoid alignment warningSerge Pavlov2018-07-051-1/+1
| | | | | | | | | | | | | | The alignment specified by a constant for the field `BumpPointerAllocator::InitialBuffer` exceeded the alignment guaranteed by `malloc` and `new` on Windows. This change set the alignment value to that of `long double`, which is defined by the used platform. It fixes https://bugs.llvm.org/show_bug.cgi?id=37944. Differential Revision: https://reviews.llvm.org/D48889 llvm-svn: 336311
* Revert r336159, r336157. Some bots failed on qualified std::max_align_t, and ↵Erik Pilkington2018-07-031-2/+1
| | | | | | | | | | | other on unqualified max_align_t. I'll take another stab at this tomorrow. Any ideas for fixing this would be appreciated! http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/23071/steps/build_Lld/logs/stdio http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/11185/steps/build-stage1-compiler/logs/stdio llvm-svn: 336162
* Some buildbots were choking on std::max_align_t, try using the global alias.Erik Pilkington2018-07-031-1/+1
| | | | llvm-svn: 336159
* [demangler] Fix a MSVC alignment warning.Erik Pilkington2018-07-031-1/+2
| | | | | | This should fix llvm.org/PR37944 llvm-svn: 336157
* Fix spelling mistakes in comments. NFCI.Simon Pilgrim2018-06-261-4/+4
| | | | llvm-svn: 335603
* Move Compiler.h from Demangle back to SupportDavid Blaikie2018-06-041-2/+70
| | | | | | | | Code review feedback from r328123 prefers copying the few feature test macros used by Demangle into there, rather than sinking the header into an odd corner like Demangle. llvm-svn: 333965
* Reverted commits 333390, 333391 and 333394Serge Pavlov2018-05-292-8/+5
| | | | | | Build of shared library LLVMDemangle.so fails due to dependency problem. llvm-svn: 333395
* Added library LLVMSupport to dependencies of LLVMDemangleSerge Pavlov2018-05-291-0/+3
| | | | | | | After r333390 build of LLVMDemangle.so fails due to unresolved reference `llvm::report_bad_alloc_error`. llvm-svn: 333394
* Use uniform mechanism for OOM errors handlingSerge Pavlov2018-05-291-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [demangler] Add ItaniumPartialDemangler::isCtorOrDtorFangrui Song2018-05-241-0/+32
| | | | | | | | | | Reviewers: erik.pilkington, ruiu, echristo, pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47248 llvm-svn: 333159
* [demangler] Add a partial demangling API for LLDB.Erik Pilkington2018-04-121-0/+191
| | | | | | | | | | 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
* [demangler] NFC: Some refactoring to support partial demangling.Erik Pilkington2018-04-121-42/+97
| | | | | | | I'm committing this to libcxxabi too so that the two demanglers remain as simular as possible. llvm-svn: 329950
* [demangler] Support for fold expressions.Erik Pilkington2018-04-091-3/+126
| | | | llvm-svn: 329601
* [demangler] Support for <data-member-prefix>.Erik Pilkington2018-04-091-0/+9
| | | | llvm-svn: 329600
* [demangler] Support for partially substituted sizeof....Erik Pilkington2018-04-091-1/+24
| | | | llvm-svn: 329599
* [demangler] Fix a bug in r328464 found by oss-fuzz.Erik Pilkington2018-03-261-2/+27
| | | | llvm-svn: 328507
* [demangler] Use a back-patching scheme to resolve forward references.Erik Pilkington2018-03-251-40/+79
| | | | | | | | | | | | | | | 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
* [demangler] Tweak how parameter pack sizes are determined.Erik Pilkington2018-03-251-210/+105
| | | | | | | | 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
* [demangler] Support for clang's enable_if attribute.Erik Pilkington2018-03-251-6/+35
| | | | | | Fixes PR33569. llvm-svn: 328462
* Reapply Support layering fixes.David Blaikie2018-03-211-4/+6
| | | | | | | | | | | | | | | | | | | | 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
* Revert layering changesJonas Devlieghere2018-03-211-6/+4
| | | | | | | | | | | | 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
* Move Compiler.h from Support to Demangler to fix layering.David Blaikie2018-03-211-4/+6
| | | | | | | | | | | | 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
OpenPOWER on IntegriCloud