summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/MicrosoftMangle.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* MS ABI: Fix the initializer/finalizer mangling for static data membersDavid Majnemer2014-03-061-0/+4
| | | | | | | Initializers and finalizers for static data members have the variable's access-specifier, storage-class, type and CV-qualifiers mangled in. llvm-svn: 203145
* MS ABI: Mangle lambdasDavid Majnemer2014-03-051-1/+32
| | | | | | | | | | | | | | | | Use a scheme inspired by the Itanium ABI to properly implement the mangling of lambdas. N.B. The incredibly astute observer will notice that we do not generate external names that are identical, or even compatible with, MSVC. This is fine because they don't generate names that they can use across translation units. Technically, we can generate any name we'd like so long as that name wouldn't conflict with any other and would be stable across translation units. This fixes PR15512. llvm-svn: 202962
* [-cxx-abi microsoft] Implement local manglings accuratelyDavid Majnemer2014-03-051-135/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The MSVC ABI appears to mangle the lexical scope into the names of statics. Specifically, a counter is incremented whenever a scope is entered where things can be declared in such a way that an ambiguity can arise. For example, a class scope inside of a class scope doesn't do anything interesting because the nested class cannot collide with another nested class. There are problems with this scheme: - It is unreliable. The counter is only incremented when a previously never encountered scope is entered. There are cases where this will cause ambiguity amongst declarations that have the same name where one was introduced in a deep scope while the other was introduced right after in the previous lexical scope. - It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}} will make the mangling of "foo" larger than it need be because the scope counter has been incremented many times. Because of these problems, and practical implementation concerns. We choose not to implement this scheme if the local static or local type isn't visible. The mangling of these declarations will look very similar but the numbering will make far more sense, this scheme is lifted from the Itanium ABI implementation. Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2953 llvm-svn: 202951
* MS ABI: Mangle variable templates properlyDavid Majnemer2014-03-041-1/+7
| | | | | | | | | | | | | We wouldn't recognize variable templates as being templates leading us to leave the template arguments off of the mangled name. This would allow two unrelated templates to map to the same mangled name. N.B. While MSVC doesn't support variable templates as of this date, this mangling is the most likely thing they will choose to use. Their demangler can successfully demangle our manglings with the template arguments shown. llvm-svn: 202789
* MS ABI: Refactor extended qualifiersDavid Majnemer2014-02-181-29/+32
| | | | | | | Extended qualifiers can appear in many places, refactor the code so it's more reusable. Add tests in areas where we've increased compatibility. llvm-svn: 201574
* MS ABI: Add support for mangling __restrictDavid Majnemer2014-02-181-9/+14
| | | | | | | | | | | | Pointer types in the MSVC ABI are a bit awkward, the width of the pointer is considered a kind of CVR qualifier. Restrict is handled similarly to const and volatile but is mangled after the pointer width qualifier. This fixes PR18880. llvm-svn: 201569
* MS ABI: Use the most recent decl to check the inheritance modelReid Kleckner2014-02-081-3/+4
| | | | | | This was crashing compilation of DeclContext::buildLookupImpl<>. llvm-svn: 201013
* MS ABI: Handle indirect field decls in template argsDavid Majnemer2014-02-061-6/+7
| | | | | | | Properly support fields that come from anonymous unions and structs when used as template arguments for pointer to data member params. llvm-svn: 200921
* MS ABI: Tweak pointer-to-member mangling/inheritance model selectionDavid Majnemer2014-02-061-31/+24
| | | | | | | | | | | | Properly determine the inheritance model when dealing with nullptr: - If a nullptr template argument is being checked against pointer-to-member parameter, nail down an inheritance model. N.B. We will chose an inheritance model even if we won't ultimately choose the template to instantiate! Cooky, right? - Null pointer-to-datamembers have a virtual base table offset of -1, not zero. Previously, we chose an offset of 0. llvm-svn: 200920
* Fix -Wunused-variable 'FD' by using it instead of ND when they're equal but FDNick Lewycky2014-02-051-2/+2
| | | | | | has a more precise type. llvm-svn: 200889
* MS ABI: Fix mangling of static methods and function referencesReid Kleckner2014-02-051-4/+9
| | | | | | | | Function references always use $1? like function pointers and never $E? like var decl references. Static methods are mangled like function pointers. llvm-svn: 200869
* MS ABI: Mangle member pointer template argumentsReid Kleckner2014-02-051-14/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Member pointers are mangled as they would be represented at runtime. They can be a single integer literal, single decl, or a tuple with some more numbers tossed in. With Clang today, most of those numbers will be zero because we reject pointers to members of virtual bases. This change required moving VTableContextBase ownership from CodeGenVTables to ASTContext, because mangling now depends on vtable layout. I also hoisted the inheritance model helpers up to be inline static methods of MSInheritanceAttr. This makes the AST code that deals with member pointers much more readable. MSVC doesn't appear to have stable manglings of null member pointers: - Null data memptrs in function templates have a mangling collision with the first field of a non-polymorphic single inheritance class. - The mangling of null data memptrs changes if you add casts. - Large null function memptrs in class templates crash MSVC. Clang uses the class template mangling for null data memptrs and the function template mangling for null function memptrs to deal with this. Reviewers: majnemer Differential Revision: http://llvm-reviews.chandlerc.com/D2695 llvm-svn: 200857
* Rename getResultType() on function and method declarations to getReturnType()Alp Toker2014-01-251-1/+1
| | | | | | | | | | | | | | | A return type is the declared or deduced part of the function type specified in the declaration. A result type is the (potentially adjusted) type of the value of an expression that calls the function. Rule of thumb: * Declarations have return types and parameters. * Expressions have result types and arguments. llvm-svn: 200082
* MSVC ABI: Support C++11's auto on variablesDavid Majnemer2014-01-211-1/+3
| | | | | | | | | | The MSVC C++ ABI always uses the deduced type in place of auto when generating external names for variables. N.B. MSVC doesn't support C++1y's 'operator auto' and this patch will not give us said functionality. llvm-svn: 199764
* Rename FunctionProtoType accessors from 'arguments' to 'parameters'Alp Toker2014-01-201-3/+4
| | | | | | | | | | | | | | | | | Fix a perennial source of confusion in the clang type system: Declarations and function prototypes have parameters to which arguments are supplied, so calling these 'arguments' was a stretch even in C mode, let alone C++ where default arguments, templates and overloading make the distinction important to get right. Readability win across the board, especially in the casting, ADL and overloading implementations which make a lot more sense at a glance now. Will keep an eye on the builders and update dependent projects shortly. No functional change. llvm-svn: 199686
* Sort all the #include lines with LLVM's utils/sort_includes.py whichChandler Carruth2014-01-071-1/+1
| | | | | | | encodes the canonical rules for LLVM's style. I noticed this had drifted quite a bit when cleaning up LLVM, so wanted to clean up Clang as well. llvm-svn: 198686
* [-cxx-abi microsoft] Remove trailing spaces from the manglerDavid Majnemer2013-12-131-16/+16
| | | | | | No functional change, just a tidying up. llvm-svn: 197196
* [-cxx-abi microsoft] Add commentary for mangleStaticGuardVariableDavid Majnemer2013-12-131-0/+9
| | | | | | | We will need to do some work here if we want to play nice with MSVC2013. Add a TODO indicating what changed and why this matters. llvm-svn: 197193
* Revert "[-cxx-abi microsoft] Mangle reference temporaries"David Majnemer2013-12-131-3/+4
| | | | | | | | | This reverts commit r197184. Richard Smith brings up some good points, a proper implementation will require us to mangle unnameable entities compatibly with MSVC. llvm-svn: 197192
* [-cxx-abi microsoft] Mangle reference temporariesDavid Majnemer2013-12-121-4/+3
| | | | | | | They are mangled the same as normal references, nothing special is going on here. llvm-svn: 197184
* [-cxx-abi microsoft] Mangle large integral constants correctlyDavid Majnemer2013-12-091-43/+40
| | | | | | | | | | | | | | | | | | | Testing has revealed that large integral constants (i.e. > INT64_MAX) are always mangled as-if they are negative, even in places where it would not make sense for them to be negative (like non-type template parameters of type unsigned long long). To address this, we change the way we model number mangling: always mangle as-if our number is an int64_t. This should result in correct results when we have large unsigned numbers. N.B. Bizarrely, things that are 32-bit displacements like vbptr offsets are mangled as-if they are unsigned 32-bit numbers. This is a pretty egregious waste of space, it would be a 4x savings if we could mangle it like a signed 32-bit number. Instead, we explicitly cast these displacements to uint32_t and let the mangler proceed. llvm-svn: 196771
* [-cxx-abi microsoft] Properly mangle enumsDavid Majnemer2013-12-091-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While testing our ability to mangle large constants (PR18175), I incidentally discovered that we did not properly mangle enums correctly. Previously, we would append the width of the enum in bytes after the type-tag differentiator. This would mean "enum : short" would be mangled as 'W2' while "enum : char" would be mangled as 'W1'. Upon testing this with several versions of MSVC, I found that this did not match their behavior: they always use 'W4'. N.B. Quick testing uncovered that undname allows different numbers to follow the 'W' in the following way: 'W0' -> "enum char" 'W1' -> "enum unsigned char" 'W2' -> "enum short" 'W3' -> "enum unsigned short" 'W4' -> "enum" 'W5' -> "enum unsigned int" 'W6' -> "enum long" 'W7' -> "enum unsigned long" However this scheme appears abandoned, I cannot get MSVC to trigger it. Furthermore, it's incomplete: it doesn't handle "bool" or "long long". llvm-svn: 196752
* Correct hyphenations in comments and assert messagesAlp Toker2013-12-051-3/+3
| | | | | | | This patch tries to avoid unrelated changes other than fixing a few hyphen-related ambiguities in nearby lines. llvm-svn: 196466
* [-cxx-abi microsoft] Create backrefs for <unnamed-type-`id'>David Majnemer2013-11-251-14/+16
| | | | | | | | | | | | | | | It wasn't possible for an anonymous type to show up inside of function arguments. However, decltype (which MSVC added support for in 2010) makes this possible. Further, backrefs to these anonymous types can now be formed. This fixes PR18022. N.B. We do not, and very likely _will not_, support MSVC's bug where subsequent typedefs of anonymous types leak into the linkage name; this is a gross violation of the ABI. A warning should be introduced to inform our users of this particular shortcoming. llvm-svn: 195669
* Add a mangler entry point for TBAA rather than using RTTI directlyReid Kleckner2013-11-191-0/+9
| | | | | | | | | | | | | | | | | | | | Summary: RTTI is not yet implemented for the Microsoft C++ ABI and isn't expected soon. We could easily add the mangling, but the error is what prevents us from silently miscompiling code that expects RTTI. Instead, add a new mangleTypeName entry point that simply forwards to mangleName or mangleType to produce a string that isn't part of the ABI. Itanium can continue to use RTTI names to avoid unecessary test breakage. This also seems like the right design. The fact that TBAA names happen to be RTTI names is now an implementation detail of the mangler, rather than part of TBAA. Differential Revision: http://llvm-reviews.chandlerc.com/D2153 llvm-svn: 195168
* [-cxx-abi microsoft] Emit thunks for pointers to virtual member functionsHans Wennborg2013-11-151-0/+15
| | | | | | | | | | | | | | | | Instead of storing the vtable offset directly in the function pointer and doing a branch to check for virtualness at each call site, the MS ABI generates a thunk for calling the function at a specific vtable offset, and puts that in the function pointer. This patch adds support for emitting such thunks. However, it doesn't support pointers to virtual member functions that are variadic, have an incomplete aggregate return type or parameter, or are overriding a function in a virtual base class. Differential Revision: http://llvm-reviews.chandlerc.com/D2104 llvm-svn: 194827
* Fix PR17738 - add support for vtordisp thunks when using -cxx-abi microsoftTimur Iskhodzhanov2013-11-061-15/+56
| | | | llvm-svn: 194132
* Rename some functions for consistency.Rafael Espindola2013-10-171-1/+1
| | | | | | Every other function in Redeclarable.h was using Decl instead of Declaration. llvm-svn: 192900
* On 32 bit windows, mangle stdcall and fastcall decls in clang.Rafael Espindola2013-10-161-22/+5
| | | | | | | | | | | This removes the dependency on the llvm mangler doing it for us. In isolation, the benefit is that the testing of what mangling is applied is all in one place: (C, C++) X (Itanium, Microsoft) are all handled by clang. This also gives me hope that in the future the llvm mangler (and llvm-ar) will not depend on TargetMachine. llvm-svn: 192762
* Reland 192220 "Abstract out parts of thunk emission code, add support for ↵Timur Iskhodzhanov2013-10-091-25/+61
| | | | | | simple thunks when using -cxx-abi microsoft" with relaxed assertions llvm-svn: 192285
* Revert 192220 as it fails on an assertionTimur Iskhodzhanov2013-10-081-61/+25
| | | | llvm-svn: 192225
* Abstract out parts of thunk emission code, add support for simple thunks ↵Timur Iskhodzhanov2013-10-081-25/+61
| | | | | | | | when using -cxx-abi microsoft Reviewed at http://llvm-reviews.chandlerc.com/D1787 llvm-svn: 192220
* [ms-cxxabi] Fix the calling convention for operator new in recordsReid Kleckner2013-10-081-3/+1
| | | | | | | | | | | | | | | | | | Summary: Operator new, new[], delete, and delete[] are all implicitly static when declared inside a record. CXXMethodDecl already knows this, but we need to account for that before we pick the calling convention for the function type. Fixes PR17371. Reviewers: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1761 llvm-svn: 192150
* Simplify MicrosoftCXXNameMangler::mangleFunctionTypeTimur Iskhodzhanov2013-10-041-19/+17
| | | | llvm-svn: 191950
* Extract ABI-specific parts of MangleContext into separate classesTimur Iskhodzhanov2013-10-031-63/+43
| | | | | | Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
* Abstract out the emission of vtables, add basic support for vtable emission ↵Timur Iskhodzhanov2013-09-271-4/+17
| | | | | | | | when using -cxx-abi microsoft Reviewed at http://llvm-reviews.chandlerc.com/D1532 llvm-svn: 191523
* Remove unused param from MicrosoftMangle::mangleCallingConvention()Reid Kleckner2013-09-251-4/+3
| | | | llvm-svn: 191405
* Revert "Revert "[-cxx-abi microsoft] Mangle local TagDecls appropriately""David Majnemer2013-09-171-3/+9
| | | | | | This reverts commit r190895 which reverted r190892. llvm-svn: 190904
* Revert "[-cxx-abi microsoft] Mangle local TagDecls appropriately"David Majnemer2013-09-171-9/+3
| | | | | | This reverts commit r190892. llvm-svn: 190895
* [-cxx-abi microsoft] Mangle local TagDecls appropriatelyDavid Majnemer2013-09-171-3/+9
| | | | | | | | | | | | | | | | | | | | | | | Summary: When selecting a mangling for an anonymous tag type: - We should first try it's typedef'd name. - If that doesn't work, we should mangle in the name of the declarator that specified it as a declaration specifier. - If that doesn't work, fall back to a static mangling of <unnamed-type>. This should make our anonymous type mangling compatible. This partially fixes PR16994; we would need to have an implementation of scope numbering to get it right (a separate issue). Reviewers: rnk, rsmith, rjmccall, cdavis5x CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1540 llvm-svn: 190892
* [-cxx-abi microsoft] Correctly identify Win32 entry pointsDavid Majnemer2013-09-161-25/+10
| | | | | | | | | | | | | | | | | | | Summary: This fixes several issues with the original implementation: - Win32 entry points cannot be in namespaces - A Win32 entry point cannot be a function template, diagnose if we it. - Win32 entry points cannot be overloaded. - Win32 entry points implicitly return, similar to main. Reviewers: rnk, rsmith, whunt, timurrrr Reviewed By: rnk CC: cfe-commits, nrieck Differential Revision: http://llvm-reviews.chandlerc.com/D1683 llvm-svn: 190818
* [-cxx-abi microsoft] Mangle user defined entry points properlyDavid Majnemer2013-09-131-2/+25
| | | | | | | | | | | | | | | | Summary: Functions named "main", "wmain", "WinMain", "wWinMain", and "DllMain" are never mangled regardless of linkage, even when compiling for kernel mode. Depends on D1655 Reviewers: timurrrr, pcc, rnk, whunt CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1670 llvm-svn: 190675
* [-cxx-abi microsoft] Mangle declarations inside extern "C"David Majnemer2013-09-131-33/+76
| | | | | | | | | | | | | | | Summary: This is a first step to getting extern "C" working properly inside clang. There are a number of quirks but mangling declarations inside such a function are a good first step. Reviewers: timurrrr, pcc, cdavis5x CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1655 llvm-svn: 190671
* [-cxx-abi microsoft] Canonicalize array parameters betterDavid Majnemer2013-09-111-27/+23
| | | | | | | | | | | | | | | Summary: More accurately characterize the nature of array parameters. Doing this removes false back-reference opportunities. Remove some hacks now that we characterize these better. Reviewers: rnk, timurrrr, whunt, cdavis5x CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1626 llvm-svn: 190488
* [ms-cxxabi] Mangle dynamic initializer stubs the same way MSVC doesReid Kleckner2013-09-101-6/+22
| | | | | | | | | | | | Summary: Dynamic initializers are mangled as ??__E <name> YAXXZ. Reviewers: timurrrr CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1477 llvm-svn: 190434
* [ms-cxxabi] Implement guard variables for static initializationReid Kleckner2013-09-101-4/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
* Add ms_abi and sysv_abi attribute handling.Charles Davis2013-08-301-0/+2
| | | | | | Based on a patch by Benno Rice! llvm-svn: 189644
* Delete CC_Default and use the target default CC everywhereReid Kleckner2013-08-271-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Makes functions with implicit calling convention compatible with function types with a matching explicit calling convention. This fixes things like calls to qsort(), which has an explicit __cdecl attribute on the comparator in Windows headers. Clang will now infer the calling convention from the declarator. There are two cases when the CC must be adjusted during redeclaration: 1. When defining a non-inline static method. 2. When redeclaring a function with an implicit or mismatched convention. Fixes PR13457, and allows clang to compile CommandLine.cpp for the Microsoft C++ ABI. Excellent test cases provided by Alexander Zinenko! Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D1231 llvm-svn: 189412
* [-cxx-abi microsoft] Remove ArgIndex, we handle all template argument kinds!David Majnemer2013-08-271-20/+6
| | | | | | | TemplateExpansion cannot happen here because MSVC doesn't mangle anything but the fully substituted template arguments. llvm-svn: 189325
* Fix virtual destructor mangling when using "-cxx-abi microsoft" on x64Timur Iskhodzhanov2013-08-261-1/+1
| | | | llvm-svn: 189214
OpenPOWER on IntegriCloud