maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/AST/MicrosoftMangle.cpp

2877 lines
107 KiB
C++
Raw Normal View History

Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
//===--- MicrosoftMangle.cpp - Microsoft Visual C++ Name Mangling ---------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This provides C++ name mangling targeting the Microsoft Visual C++ ABI.
//
//===----------------------------------------------------------------------===//
#include "clang/AST/Mangle.h"
#include "clang/AST/ASTContext.h"
#include "clang/AST/Attr.h"
Reland 192220 "Abstract out parts of thunk emission code, add support for simple thunks when using -cxx-abi microsoft" with relaxed assertions llvm-svn: 192285
2013-10-09 17:23:58 +08:00
#include "clang/AST/CXXInheritance.h"
Sort all the #include lines with LLVM's utils/sort_includes.py which 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
2014-01-07 19:51:46 +08:00
#include "clang/AST/CharUnits.h"
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
#include "clang/AST/Decl.h"
#include "clang/AST/DeclCXX.h"
#include "clang/AST/DeclObjC.h"
#include "clang/AST/DeclTemplate.h"
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
#include "clang/AST/Expr.h"
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
#include "clang/AST/ExprCXX.h"
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
#include "clang/AST/VTableBuilder.h"
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
#include "clang/Basic/ABI.h"
#include "clang/Basic/DiagnosticOptions.h"
[ms-cxxabi] Mangle in an implicit 'E' for certain types on win64 Most of the complexity of this patch is figuring out which types get the qualifier and which don't. If we implement __ptr32/64, then we should check the qualifier instead of assuming all pointers are 64-bit. This fixes PR13792. Patch by Warren Hunt! llvm-svn: 181825
2013-05-15 04:30:42 +08:00
#include "clang/Basic/TargetInfo.h"
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
#include "llvm/ADT/StringExtras.h"
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
#include "llvm/Support/MathExtras.h"
[MS ABI] Switch to the CRC implementation in LLVM We now have an implementation of the CRC in LLVM's libSupport. Let's consolidate around that one. llvm-svn: 246591
2015-09-02 05:24:07 +08:00
#include "llvm/Support/JamCRC.h"
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. llvm-svn: 204562
2014-03-24 01:47:16 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
using namespace clang;
namespace {
[-cxx-abi microsoft] Mangle declarations inside extern "C" 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
2013-09-13 17:03:14 +08:00
/// \brief Retrieve the declaration context that should be used when mangling
/// the given declaration.
static const DeclContext *getEffectiveDeclContext(const Decl *D) {
// The ABI assumes that lambda closure types that occur within
// default arguments live in the context of the function. However, due to
// the way in which Clang parses and creates function declarations, this is
// not the case: the lambda closure type ends up living in the context
// where the function itself resides, because the function declaration itself
// had not yet been created. Fix the context here.
if (const CXXRecordDecl *RD = dyn_cast<CXXRecordDecl>(D)) {
if (RD->isLambda())
if (ParmVarDecl *ContextParam =
dyn_cast_or_null<ParmVarDecl>(RD->getLambdaContextDecl()))
return ContextParam->getDeclContext();
}
// Perform the same check for block literals.
if (const BlockDecl *BD = dyn_cast<BlockDecl>(D)) {
if (ParmVarDecl *ContextParam =
dyn_cast_or_null<ParmVarDecl>(BD->getBlockManglingContextDecl()))
return ContextParam->getDeclContext();
}
const DeclContext *DC = D->getDeclContext();
if (const CapturedDecl *CD = dyn_cast<CapturedDecl>(DC))
return getEffectiveDeclContext(CD);
return DC;
}
static const DeclContext *getEffectiveParentContext(const DeclContext *DC) {
return getEffectiveDeclContext(cast<Decl>(DC));
}
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
static const FunctionDecl *getStructor(const NamedDecl *ND) {
if (const auto *FTD = dyn_cast<FunctionTemplateDecl>(ND))
return FTD->getTemplatedDecl();
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
const auto *FD = cast<FunctionDecl>(ND);
if (const auto *FTD = FD->getPrimaryTemplate())
return FTD->getTemplatedDecl();
return FD;
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
}
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
static bool isLambda(const NamedDecl *ND) {
const CXXRecordDecl *Record = dyn_cast<CXXRecordDecl>(ND);
if (!Record)
return false;
return Record->isLambda();
}
/// MicrosoftMangleContextImpl - Overrides the default MangleContext for the
/// Microsoft Visual C++ ABI.
class MicrosoftMangleContextImpl : public MicrosoftMangleContext {
typedef std::pair<const DeclContext *, IdentifierInfo *> DiscriminatorKeyTy;
llvm::DenseMap<DiscriminatorKeyTy, unsigned> Discriminator;
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
llvm::DenseMap<const NamedDecl *, unsigned> Uniquifier;
MS ABI: Mangle lambdas 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
2014-03-05 18:35:06 +08:00
llvm::DenseMap<const CXXRecordDecl *, unsigned> LambdaIds;
Initial support for Win64 SEH IR emission The lowering looks a lot like normal EH lowering, with the exception that the exceptions are caught by executing filter expression code instead of matching typeinfo globals. The filter expressions are outlined into functions which are used in landingpad clauses where typeinfo would normally go. Major aspects that still need work: - Non-call exceptions in __try bodies won't work yet. The plan is to outline the __try block in the frontend to keep things simple. - Filter expressions cannot use local variables until capturing is implemented. - __finally blocks will not run after exceptions. Fixing this requires work in the LLVM SEH preparation pass. The IR lowering looks like this: // C code: bool safe_div(int n, int d, int *r) { __try { *r = normal_div(n, d); } __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) { return false; } return true; } ; LLVM IR: define i32 @filter(i8* %e, i8* %fp) { %ehptrs = bitcast i8* %e to i32** %ehrec = load i32** %ehptrs %code = load i32* %ehrec %matches = icmp eq i32 %code, i32 u0xC0000094 %matches.i32 = zext i1 %matches to i32 ret i32 %matches.i32 } define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) { %rr = invoke i32 @normal_div(i32 %n, i32 %d) to label %normal unwind to label %lpad normal: store i32 %rr, i32* %r ret i1 1 lpad: %ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*) %ehptr = extractvalue {i8*, i32} %ehvals, i32 0 %sel = extractvalue {i8*, i32} %ehvals, i32 1 %filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*)) %matches = icmp eq i32 %sel, %filter_sel br i1 %matches, label %eh.except, label %eh.resume eh.except: ret i1 false eh.resume: resume } Reviewers: rjmccall, rsmith, majnemer Differential Revision: http://reviews.llvm.org/D5607 llvm-svn: 226760
2015-01-22 09:36:17 +08:00
llvm::DenseMap<const NamedDecl *, unsigned> SEHFilterIds;
Reland r234613 (and follow-ups 234614, 234616, 234618) The frameescape intrinsic cannot be inlined, so I fixed the inliner in r234937. This should address PR23216. llvm-svn: 234942
2015-04-15 04:59:00 +08:00
llvm::DenseMap<const NamedDecl *, unsigned> SEHFinallyIds;
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
public:
MicrosoftMangleContextImpl(ASTContext &Context, DiagnosticsEngine &Diags)
: MicrosoftMangleContext(Context, Diags) {}
[C++11] Add 'override' keyword to virtual methods that override their base class. llvm-svn: 203543
2014-03-11 14:22:39 +08:00
bool shouldMangleCXXName(const NamedDecl *D) override;
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
bool shouldMangleStringLiteral(const StringLiteral *SL) override;
[C++11] Add 'override' keyword to virtual methods that override their base class. llvm-svn: 203543
2014-03-11 14:22:39 +08:00
void mangleCXXName(const NamedDecl *D, raw_ostream &Out) override;
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
void mangleVirtualMemPtrThunk(const CXXMethodDecl *MD,
raw_ostream &) override;
[C++11] Add 'override' keyword to virtual methods that override their base class. llvm-svn: 203543
2014-03-11 14:22:39 +08:00
void mangleThunk(const CXXMethodDecl *MD, const ThunkInfo &Thunk,
raw_ostream &) override;
void mangleCXXDtorThunk(const CXXDestructorDecl *DD, CXXDtorType Type,
const ThisAdjustment &ThisAdjustment,
raw_ostream &) override;
void mangleCXXVFTable(const CXXRecordDecl *Derived,
ArrayRef<const CXXRecordDecl *> BasePath,
raw_ostream &Out) override;
void mangleCXXVBTable(const CXXRecordDecl *Derived,
ArrayRef<const CXXRecordDecl *> BasePath,
raw_ostream &Out) override;
[MS ABI] Rework member pointer conversion Member pointers in the MS ABI are made complicated due to the following: - Virtual methods in the most derived class (MDC) might live in a vftable in a virtual base. - There are four different representations of member pointer: single inheritance, multiple inheritance, virtual inheritance and the "most general" representation. - Bases might have a *more* general representation than classes which derived from them, a most surprising result. We believed that we could treat all member pointers as-if they were a degenerate case of the multiple inheritance model. This fell apart once we realized that implementing standard member pointers using this ABI requires referencing members with a non-zero vbindex. On a bright note, all but the virtual inheritance model operate rather similarly. The virtual inheritance member pointer representation awkwardly requires a virtual base adjustment in order to refer to entities in the MDC. However, the first virtual base might be quite far from the start of the virtual base. This means that we must add a negative non-virtual displacement. However, things get even more complicated. The most general representation interprets vbindex zero differently from the virtual inheritance model: it doesn't reference the vbtable at all. It turns out that this complexity can increase for quite some time: consider a derived to base conversion from the most general model to the multiple inheritance model... To manage this complexity we introduce a concept of "normalized" member pointer which allows us to treat all three models as the most general model. Then we try to figure out how to map this generalized member pointer onto the destination member pointer model. I've done my best to furnish the code with comments explaining why each adjustment is performed. This fixes PR23878. llvm-svn: 240384
2015-06-23 15:31:11 +08:00
void mangleCXXVirtualDisplacementMap(const CXXRecordDecl *SrcRD,
const CXXRecordDecl *DstRD,
raw_ostream &Out) override;
MS ABI: Implement support for throwing a C++ exception Throwing a C++ exception, under the MS ABI, is implemented using three components: - ThrowInfo structure which contains information like CV qualifiers, what destructor to call and a pointer to the CatchableTypeArray. - In a significant departure from the Itanium ABI, copying by-value occurs in the runtime and not at the catch site. This means we need to enumerate all possible types that this exception could be caught as and encode the necessary information to convert from the exception object's type to the catch handler's type. This includes complicated derived to base conversions and the execution of copy-constructors. N.B. This implementation doesn't support the execution of a copy-constructor from within the runtime for now. Adding support for that functionality is quite difficult due to things like default argument expressions which may evaluate arbitrary code hiding in the copy-constructor's parameters. Differential Revision: http://reviews.llvm.org/D8066 llvm-svn: 231328
2015-03-05 08:46:22 +08:00
void mangleCXXThrowInfo(QualType T, bool IsConst, bool IsVolatile,
uint32_t NumEntries, raw_ostream &Out) override;
void mangleCXXCatchableTypeArray(QualType T, uint32_t NumEntries,
raw_ostream &Out) override;
MS ABI: Insert copy-constructors into the CatchableType Find all unambiguous public classes of the exception object's class type and reference all of their copy constructors. Yes, this is not conforming but it is necessary in order to implement their ABI. This is because the copy constructor is actually referenced by the metadata describing which catch handlers are eligible to handle the exception object. N.B. This doesn't yet handle the copy constructor closure case yet, that work is ongoing. Differential Revision: http://reviews.llvm.org/D8101 llvm-svn: 231499
2015-03-07 02:53:55 +08:00
void mangleCXXCatchableType(QualType T, const CXXConstructorDecl *CD,
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
CXXCtorType CT, uint32_t Size, uint32_t NVOffset,
MS ABI: Mangle the location of the catchable type into it's name Because the catchable type has a reference to its name, mangle the location to ensure that two catchable types with different locations are distinct. llvm-svn: 231819
2015-03-11 03:01:51 +08:00
int32_t VBPtrOffset, uint32_t VBIndex,
raw_ostream &Out) override;
[MS ABI] Rework .xdata HandlerType emission Utilizing IMAGEREL relocations for synthetic IR constructs isn't valuable, just clutter. While we are here, simplify HandlerType names by making the numeric value for the 'adjective' part of the mangled name instead of appending '.const', etc. The old scheme made for very long global names and leads to wordy things like '.std_bad_alloc' llvm-svn: 233503
2015-03-30 05:55:10 +08:00
void mangleCXXCatchHandlerType(QualType T, uint32_t Flags,
raw_ostream &Out) override;
MS ABI: Preliminary RTTI mangling Implement what we currently believe is the mangling scheme for RTTI data. Tests will be added in a later commit which actually generate RTTI data. llvm-svn: 208661
2014-05-13 08:44:44 +08:00
void mangleCXXRTTI(QualType T, raw_ostream &Out) override;
void mangleCXXRTTIName(QualType T, raw_ostream &Out) override;
MS ABI: Tighten RTTI mangling r208661 contained WIP code, commit the *actual* manglings. llvm-svn: 208668
2014-05-13 14:57:43 +08:00
void mangleCXXRTTIBaseClassDescriptor(const CXXRecordDecl *Derived,
[MS-ABI] Implements MS-compatible RTTI Enables the emission of MS-compatible RTTI data structures for use with typeid, dynamic_cast and exceptions. Does not implement dynamic_cast or exceptions. As an artiface, typeid works in some cases but proper support an testing will coming in a subsequent patch. majnemer has fuzzed the results. Test cases included. Differential Revision: http://reviews.llvm.org/D3833 llvm-svn: 209523
2014-05-24 00:07:43 +08:00
uint32_t NVOffset, int32_t VBPtrOffset,
MS ABI: Tighten RTTI mangling r208661 contained WIP code, commit the *actual* manglings. llvm-svn: 208668
2014-05-13 14:57:43 +08:00
uint32_t VBTableOffset, uint32_t Flags,
raw_ostream &Out) override;
MS ABI: Preliminary RTTI mangling Implement what we currently believe is the mangling scheme for RTTI data. Tests will be added in a later commit which actually generate RTTI data. llvm-svn: 208661
2014-05-13 08:44:44 +08:00
void mangleCXXRTTIBaseClassArray(const CXXRecordDecl *Derived,
raw_ostream &Out) override;
void mangleCXXRTTIClassHierarchyDescriptor(const CXXRecordDecl *Derived,
raw_ostream &Out) override;
MS ABI: Tighten RTTI mangling r208661 contained WIP code, commit the *actual* manglings. llvm-svn: 208668
2014-05-13 14:57:43 +08:00
void
mangleCXXRTTICompleteObjectLocator(const CXXRecordDecl *Derived,
ArrayRef<const CXXRecordDecl *> BasePath,
raw_ostream &Out) override;
[C++11] Add 'override' keyword to virtual methods that override their base class. llvm-svn: 203543
2014-03-11 14:22:39 +08:00
void mangleTypeName(QualType T, raw_ostream &) override;
void mangleCXXCtor(const CXXConstructorDecl *D, CXXCtorType Type,
raw_ostream &) override;
void mangleCXXDtor(const CXXDestructorDecl *D, CXXDtorType Type,
raw_ostream &) override;
AST: Mangle reference temporaries reliably Summary: Previously, we would generate a single name for all reference temporaries and allow LLVM to rename them for us. Instead, number the reference temporaries as we build them in Sema. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3554 llvm-svn: 207776
2014-05-02 01:50:17 +08:00
void mangleReferenceTemporary(const VarDecl *, unsigned ManglingNumber,
raw_ostream &) override;
[C++11] Add 'override' keyword to virtual methods that override their base class. llvm-svn: 203543
2014-03-11 14:22:39 +08:00
void mangleStaticGuardVariable(const VarDecl *D, raw_ostream &Out) override;
[MS ABI] Implement thread-safe initialization using the MSVC 2015 ABI The MSVC 2015 ABI utilizes a rather straightforward adaptation of the algorithm found in the appendix of N2382. While we are here, implement support for emitting cleanups if an exception is thrown while we are intitializing a static local variable. llvm-svn: 236697
2015-05-07 14:15:46 +08:00
void mangleThreadSafeStaticGuardVariable(const VarDecl *D, unsigned GuardNum,
raw_ostream &Out) override;
[C++11] Add 'override' keyword to virtual methods that override their base class. llvm-svn: 203543
2014-03-11 14:22:39 +08:00
void mangleDynamicInitializer(const VarDecl *D, raw_ostream &Out) override;
void mangleDynamicAtExitDestructor(const VarDecl *D,
raw_ostream &Out) override;
Initial support for Win64 SEH IR emission The lowering looks a lot like normal EH lowering, with the exception that the exceptions are caught by executing filter expression code instead of matching typeinfo globals. The filter expressions are outlined into functions which are used in landingpad clauses where typeinfo would normally go. Major aspects that still need work: - Non-call exceptions in __try bodies won't work yet. The plan is to outline the __try block in the frontend to keep things simple. - Filter expressions cannot use local variables until capturing is implemented. - __finally blocks will not run after exceptions. Fixing this requires work in the LLVM SEH preparation pass. The IR lowering looks like this: // C code: bool safe_div(int n, int d, int *r) { __try { *r = normal_div(n, d); } __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) { return false; } return true; } ; LLVM IR: define i32 @filter(i8* %e, i8* %fp) { %ehptrs = bitcast i8* %e to i32** %ehrec = load i32** %ehptrs %code = load i32* %ehrec %matches = icmp eq i32 %code, i32 u0xC0000094 %matches.i32 = zext i1 %matches to i32 ret i32 %matches.i32 } define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) { %rr = invoke i32 @normal_div(i32 %n, i32 %d) to label %normal unwind to label %lpad normal: store i32 %rr, i32* %r ret i1 1 lpad: %ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*) %ehptr = extractvalue {i8*, i32} %ehvals, i32 0 %sel = extractvalue {i8*, i32} %ehvals, i32 1 %filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*)) %matches = icmp eq i32 %sel, %filter_sel br i1 %matches, label %eh.except, label %eh.resume eh.except: ret i1 false eh.resume: resume } Reviewers: rjmccall, rsmith, majnemer Differential Revision: http://reviews.llvm.org/D5607 llvm-svn: 226760
2015-01-22 09:36:17 +08:00
void mangleSEHFilterExpression(const NamedDecl *EnclosingDecl,
raw_ostream &Out) override;
Reland r234613 (and follow-ups 234614, 234616, 234618) The frameescape intrinsic cannot be inlined, so I fixed the inliner in r234937. This should address PR23216. llvm-svn: 234942
2015-04-15 04:59:00 +08:00
void mangleSEHFinallyBlock(const NamedDecl *EnclosingDecl,
raw_ostream &Out) override;
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
void mangleStringLiteral(const StringLiteral *SL, raw_ostream &Out) override;
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
bool getNextDiscriminator(const NamedDecl *ND, unsigned &disc) {
// Lambda closure types are already numbered.
if (isLambda(ND))
return false;
const DeclContext *DC = getEffectiveDeclContext(ND);
if (!DC->isFunctionOrMethod())
return false;
// Use the canonical number for externally visible decls.
if (ND->isExternallyVisible()) {
disc = getASTContext().getManglingNumber(ND);
return true;
}
// Anonymous tags are already numbered.
if (const TagDecl *Tag = dyn_cast<TagDecl>(ND)) {
[MS ABI] Number unnamed TagDecls which aren't externally visible TagDecls (structs, enums, etc.) may have the same name for linkage purposes of one another; to disambiguate, we add a number to the mangled named. However, we didn't do this if the TagDecl has a pseudo-name for linkage purposes (it was defined alongside a DeclaratorDecl or a TypeNameDecl). This fixes PR24651. llvm-svn: 246659
2015-09-02 23:50:38 +08:00
if (!Tag->hasNameForLinkage() &&
!getASTContext().getDeclaratorForUnnamedTagDecl(Tag) &&
!getASTContext().getTypedefNameForUnnamedTagDecl(Tag))
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
return false;
}
// Make up a reasonable number for internal decls.
unsigned &discriminator = Uniquifier[ND];
if (!discriminator)
discriminator = ++Discriminator[std::make_pair(DC, ND->getIdentifier())];
MS ABI: Use '1' (instead of '0') relative scope discriminators This changes the scope discriminator's behavior to start at '1' instead of '0'. Symbol table diffing, for ABI compatibility testing, kept finding these as false positives. llvm-svn: 219075
2014-10-05 14:44:53 +08:00
disc = discriminator + 1;
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
return true;
}
MS ABI: Mangle lambdas 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
2014-03-05 18:35:06 +08:00
unsigned getLambdaId(const CXXRecordDecl *RD) {
assert(RD->isLambda() && "RD must be a lambda!");
assert(!RD->isExternallyVisible() && "RD must not be visible!");
assert(RD->getLambdaManglingNumber() == 0 &&
"RD must not have a mangling number!");
std::pair<llvm::DenseMap<const CXXRecordDecl *, unsigned>::iterator, bool>
Result = LambdaIds.insert(std::make_pair(RD, LambdaIds.size()));
return Result.first->second;
}
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
private:
void mangleInitFiniStub(const VarDecl *D, raw_ostream &Out, char CharCode);
};
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
/// MicrosoftCXXNameMangler - Manage the mangling of a single name for the
/// Microsoft Visual C++ ABI.
class MicrosoftCXXNameMangler {
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
MicrosoftMangleContextImpl &Context;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
raw_ostream &Out;
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
/// The "structor" is the top-level declaration being mangled, if
/// that's not a template specialization; otherwise it's the pattern
/// for that specialization.
const NamedDecl *Structor;
unsigned StructorType;
MS ABI: Avoid hashing back reference keys in mangler This patch replaces the back reference StringMap from the MS mangler with a SmallVector of strings. My previous patches reduced the number of hashes involved in back reference lookups, this one removes them completely. The back reference map contains at most 10 entries, which are likely to be of varying sizes and different initial subsequences, and which can easily became huge (due to templates and namespaces). The solution presented is the simplest possible one. Nevertheless, it's enough to reduce compilation times for a particular test case from 11.1s to 9s, versus 8.58s for the Itanium ABI. Possible further improvements include using a sorted vector (carefully to not introduce an extra comparison), storing the string contents in a common arena, and/or keep the string storage in the context for reuse. Patch by Agustín Bergé. llvm-svn: 218461
2014-09-26 03:43:56 +08:00
typedef llvm::SmallVector<std::string, 10> BackRefVec;
BackRefVec NameBackReferences;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
typedef llvm::DenseMap<void *, unsigned> ArgBackRefMap;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
ArgBackRefMap TypeBackReferences;
ASTContext &getASTContext() const { return Context.getASTContext(); }
[ms-cxxabi] Mangle in an implicit 'E' for certain types on win64 Most of the complexity of this patch is figuring out which types get the qualifier and which don't. If we implement __ptr32/64, then we should check the qualifier instead of assuming all pointers are 64-bit. This fixes PR13792. Patch by Warren Hunt! llvm-svn: 181825
2013-05-15 04:30:42 +08:00
// FIXME: If we add support for __ptr32/64 qualifiers, then we should push
// this check into mangleQualifiers().
const bool PointersAre64Bit;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
public:
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
enum QualifierMangleMode { QMM_Drop, QMM_Mangle, QMM_Escape, QMM_Result };
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
MicrosoftCXXNameMangler(MicrosoftMangleContextImpl &C, raw_ostream &Out_)
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
: Context(C), Out(Out_), Structor(nullptr), StructorType(-1),
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
PointersAre64Bit(C.getASTContext().getTargetInfo().getPointerWidth(0) ==
64) {}
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
MicrosoftCXXNameMangler(MicrosoftMangleContextImpl &C, raw_ostream &Out_,
const CXXConstructorDecl *D, CXXCtorType Type)
: Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
PointersAre64Bit(C.getASTContext().getTargetInfo().getPointerWidth(0) ==
64) {}
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
MicrosoftCXXNameMangler(MicrosoftMangleContextImpl &C, raw_ostream &Out_,
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
const CXXDestructorDecl *D, CXXDtorType Type)
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
: Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
PointersAre64Bit(C.getASTContext().getTargetInfo().getPointerWidth(0) ==
64) {}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
raw_ostream &getStream() const { return Out; }
void mangle(const NamedDecl *D, StringRef Prefix = "\01?");
void mangleName(const NamedDecl *ND);
[MS ABI] Function encodings are always encoded in template arguments llvm-svn: 237547
2015-05-18 08:05:25 +08:00
void mangleFunctionEncoding(const FunctionDecl *FD, bool ShouldMangle);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void mangleVariableEncoding(const VarDecl *VD);
MS ABI: Handle indirect field decls in template args Properly support fields that come from anonymous unions and structs when used as template arguments for pointer to data member params. llvm-svn: 200921
2014-02-06 20:46:52 +08:00
void mangleMemberDataPointer(const CXXRecordDecl *RD, const ValueDecl *VD);
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
void mangleMemberFunctionPointer(const CXXRecordDecl *RD,
const CXXMethodDecl *MD);
void mangleVirtualMemPtrThunk(
const CXXMethodDecl *MD,
const MicrosoftVTableContext::MethodVFTableLocation &ML);
[-cxx-abi microsoft] Mangle large integral constants correctly 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
2013-12-09 18:44:32 +08:00
void mangleNumber(int64_t Number);
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
void mangleType(QualType T, SourceRange Range,
QualifierMangleMode QMM = QMM_Mangle);
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
void mangleFunctionType(const FunctionType *T,
const FunctionDecl *D = nullptr,
MS ABI: Mangle this qualifiers on function types C++11 allows this qualifiers to exist on function types when used in template arguments. Previously, I believed it wasn't possible because MSVC rejected declarations like: S<int () const &> s; However, it turns out MSVC properly allows them in using declarations; updated clang to be compatible with this mangling. llvm-svn: 215464
2014-08-13 01:53:10 +08:00
bool ForceThisQuals = false);
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
void mangleNestedName(const NamedDecl *ND);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
private:
void mangleUnqualifiedName(const NamedDecl *ND) {
mangleUnqualifiedName(ND, ND->getDeclName());
}
void mangleUnqualifiedName(const NamedDecl *ND, DeclarationName Name);
[-cxx-abi microsoft] Create backrefs for <unnamed-type-`id'> 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
2013-11-26 01:50:19 +08:00
void mangleSourceName(StringRef Name);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void mangleOperatorName(OverloadedOperatorKind OO, SourceLocation Loc);
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
void mangleCXXDtorType(CXXDtorType T);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void mangleQualifiers(Qualifiers Quals, bool IsMember);
MS ABI: Implement mangling for ref-qualifiers on methods Mangle ref-qualifiers like the Nov 2013 CTP. This fixes PR19361. llvm-svn: 206946
2014-04-23 13:16:56 +08:00
void mangleRefQualifier(RefQualifierKind RefQualifier);
MS ABI: Refactor extended qualifiers 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
2014-02-18 22:20:10 +08:00
void manglePointerCVQualifiers(Qualifiers Quals);
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void manglePointerExtQualifiers(Qualifiers Quals, QualType PointeeType);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void mangleUnscopedTemplateName(const TemplateDecl *ND);
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
void
mangleTemplateInstantiationName(const TemplateDecl *TD,
const TemplateArgumentList &TemplateArgs);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void mangleObjCMethodName(const ObjCMethodDecl *MD);
void mangleArgumentType(QualType T, SourceRange Range);
// Declare manglers for every type class.
#define ABSTRACT_TYPE(CLASS, PARENT)
#define NON_CANONICAL_TYPE(CLASS, PARENT)
#define TYPE(CLASS, PARENT) void mangleType(const CLASS##Type *T, \
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers Quals, \
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range);
#include "clang/AST/TypeNodes.def"
#undef ABSTRACT_TYPE
#undef NON_CANONICAL_TYPE
#undef TYPE
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
[ms-cxxabi] Handle template-template arguments Template-template arguments appear to be a rather simple encoding of the template's templated tag type. llvm-svn: 187751
2013-08-06 06:26:46 +08:00
void mangleType(const TagDecl *TD);
[-cxx-abi microsoft] Canonicalize array parameters better 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
2013-09-11 12:44:30 +08:00
void mangleDecayedArrayType(const ArrayType *T);
[ms-cxxabi] Use sugared types in the mangler instead of canonical types At this point, it's clear that the MSVC mangler uses the type-as-written instead of the canonical type, so this should bring us closer to MSVC. The main thrust of this change is to fix the way we mangle decayed array parameters of function pointer parameters. With a DecayedType sugar node, this code can now be much simpler. Fixes PR16096. This also fixes a separate issue that Richard spotted in review. Because separate declarations of the same entity can be spelled and mangled differently, MSVC always mangles the earliest declaration in an attempt to avoid link errors. Clang now does the same. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D844 llvm-svn: 184777
2013-06-25 03:21:52 +08:00
void mangleArrayType(const ArrayType *T);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void mangleFunctionClass(const FunctionDecl *FD);
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
void mangleCallingConvention(CallingConv CC);
Remove unused param from MicrosoftMangle::mangleCallingConvention() llvm-svn: 191405
2013-09-26 06:28:52 +08:00
void mangleCallingConvention(const FunctionType *T);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void mangleIntegerLiteral(const llvm::APSInt &Number, bool IsBoolean);
void mangleExpression(const Expr *E);
void mangleThrowSpecification(const FunctionProtoType *T);
[ms-cxxabi] Fix assertion on unhandled function template arg types This code was changed in r158376 to get template argument source info for better diagnostics, but the current code asserts for any kind of unsupported template argument before it can issue a diagnostic. This change goes back to the Itanium implementation of isTemplate() and puts the argument index into the diagnostic instead of a source location. Review URL: http://llvm-reviews.chandlerc.com/D553 llvm-svn: 177471
2013-03-20 09:40:23 +08:00
void mangleTemplateArgs(const TemplateDecl *TD,
const TemplateArgumentList &TemplateArgs);
MS ABI: Mangle empty type parameter packs compatibly The MS mangling scheme apparently has separate manglings for type and non-type parameter packs when they are empty. Match template arguments with parameters during mangling; check the parameter to see if it was destined to hold type-ish things or nontype-ish things. Differential Revision: http://reviews.llvm.org/D4792 llvm-svn: 214932
2014-08-06 06:43:45 +08:00
void mangleTemplateArg(const TemplateDecl *TD, const TemplateArgument &TA,
const NamedDecl *Parm);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
};
Revert r240270 ("Fixed/added namespace ending comments using clang-tidy"). llvm-svn: 240353
2015-06-23 07:07:51 +08:00
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
On 32 bit windows, mangle stdcall and fastcall decls in clang. 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
2013-10-16 09:40:34 +08:00
bool MicrosoftMangleContextImpl::shouldMangleCXXName(const NamedDecl *D) {
[-cxx-abi microsoft] Mangle declarations inside extern "C" 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
2013-09-13 17:03:14 +08:00
if (const FunctionDecl *FD = dyn_cast<FunctionDecl>(D)) {
LanguageLinkage L = FD->getLanguageLinkage();
// Overloadable functions need mangling.
if (FD->hasAttr<OverloadableAttr>())
return true;
[-cxx-abi microsoft] Correctly identify Win32 entry points 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
2013-09-17 06:44:20 +08:00
// The ABI expects that we would never mangle "typical" user-defined entry
// points regardless of visibility or freestanding-ness.
//
// N.B. This is distinct from asking about "main". "main" has a lot of
// special rules associated with it in the standard while these
// user-defined entry points are outside of the purview of the standard.
// For example, there can be only one definition for "main" in a standards
// compliant program; however nothing forbids the existence of wmain and
// WinMain in the same translation unit.
if (FD->isMSVCRTEntryPoint())
[-cxx-abi microsoft] Mangle declarations inside extern "C" 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
2013-09-13 17:03:14 +08:00
return false;
// C++ functions and those whose names are not a simple identifier need
// mangling.
if (!FD->getDeclName().isIdentifier() || L == CXXLanguageLinkage)
return true;
// C functions are not mangled.
if (L == CLanguageLinkage)
return false;
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// Otherwise, no mangling is done outside C++ mode.
if (!getASTContext().getLangOpts().CPlusPlus)
return false;
[-cxx-abi microsoft] Mangle declarations inside extern "C" 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
2013-09-13 17:03:14 +08:00
if (const VarDecl *VD = dyn_cast<VarDecl>(D)) {
// C variables are not mangled.
if (VD->isExternC())
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
return false;
[-cxx-abi microsoft] Mangle declarations inside extern "C" 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
2013-09-13 17:03:14 +08:00
// Variables at global scope with non-internal linkage are not mangled.
const DeclContext *DC = getEffectiveDeclContext(D);
// Check for extern variable declared locally.
if (DC->isFunctionOrMethod() && D->hasLinkage())
while (!DC->isNamespace() && !DC->isTranslationUnit())
DC = getEffectiveParentContext(DC);
if (DC->isTranslationUnit() && D->getFormalLinkage() == InternalLinkage &&
!isa<VarTemplateSpecializationDecl>(D))
return false;
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
return true;
}
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
bool
MicrosoftMangleContextImpl::shouldMangleStringLiteral(const StringLiteral *SL) {
Simplify MicrosoftMangleContextImpl::shouldMangleStringLiteral No functionality changed. llvm-svn: 222610
2014-11-22 14:20:38 +08:00
return true;
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
}
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
void MicrosoftCXXNameMangler::mangle(const NamedDecl *D, StringRef Prefix) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// MSVC doesn't mangle C++ names the same way it mangles extern "C" names.
// Therefore it's really important that we don't decorate the
// name with leading underscores or leading/trailing at signs. So, by
// default, we emit an asm marker at the start so we get the name right.
// Callers can override this with a custom prefix.
// <mangled-name> ::= ? <name> <type-encoding>
Out << Prefix;
mangleName(D);
if (const FunctionDecl *FD = dyn_cast<FunctionDecl>(D))
[MS ABI] Function encodings are always encoded in template arguments llvm-svn: 237547
2015-05-18 08:05:25 +08:00
mangleFunctionEncoding(FD, Context.shouldMangleDeclName(FD));
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
else if (const VarDecl *VD = dyn_cast<VarDecl>(D))
mangleVariableEncoding(VD);
else {
// TODO: Fields? Can MSVC even mangle them?
// Issue a diagnostic for now.
DiagnosticsEngine &Diags = Context.getDiags();
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
unsigned DiagID = Diags.getCustomDiagID(
DiagnosticsEngine::Error, "cannot mangle this declaration yet");
Diags.Report(D->getLocation(), DiagID) << D->getSourceRange();
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
}
[MS ABI] Function encodings are always encoded in template arguments llvm-svn: 237547
2015-05-18 08:05:25 +08:00
void MicrosoftCXXNameMangler::mangleFunctionEncoding(const FunctionDecl *FD,
bool ShouldMangle) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// <type-encoding> ::= <function-class> <function-type>
[ms-cxxabi] Use sugared types in the mangler instead of canonical types At this point, it's clear that the MSVC mangler uses the type-as-written instead of the canonical type, so this should bring us closer to MSVC. The main thrust of this change is to fix the way we mangle decayed array parameters of function pointer parameters. With a DecayedType sugar node, this code can now be much simpler. Fixes PR16096. This also fixes a separate issue that Richard spotted in review. Because separate declarations of the same entity can be spelled and mangled differently, MSVC always mangles the earliest declaration in an attempt to avoid link errors. Clang now does the same. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D844 llvm-svn: 184777
2013-06-25 03:21:52 +08:00
// Since MSVC operates on the type as written and not the canonical type, it
// actually matters which decl we have here. MSVC appears to choose the
// first, since it is most likely to be the declaration in a header file.
Rename some functions for consistency. Every other function in Redeclarable.h was using Decl instead of Declaration. llvm-svn: 192900
2013-10-17 23:37:26 +08:00
FD = FD->getFirstDecl();
[ms-cxxabi] Use sugared types in the mangler instead of canonical types At this point, it's clear that the MSVC mangler uses the type-as-written instead of the canonical type, so this should bring us closer to MSVC. The main thrust of this change is to fix the way we mangle decayed array parameters of function pointer parameters. With a DecayedType sugar node, this code can now be much simpler. Fixes PR16096. This also fixes a separate issue that Richard spotted in review. Because separate declarations of the same entity can be spelled and mangled differently, MSVC always mangles the earliest declaration in an attempt to avoid link errors. Clang now does the same. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D844 llvm-svn: 184777
2013-06-25 03:21:52 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// We should never ever see a FunctionNoProtoType at this point.
// We don't even know how to mangle their types anyway :).
[ms-cxxabi] Fix the calling convention for operator new in records 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
2013-10-08 08:58:57 +08:00
const FunctionProtoType *FT = FD->getType()->castAs<FunctionProtoType>();
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
[-cxx-abi microsoft] Mangle declarations inside extern "C" 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
2013-09-13 17:03:14 +08:00
// extern "C" functions can hold entities that must be mangled.
// As it stands, these functions still need to get expressed in the full
// external name. They have their class and type omitted, replaced with '9'.
[MS ABI] Function encodings are always encoded in template arguments llvm-svn: 237547
2015-05-18 08:05:25 +08:00
if (ShouldMangle) {
[MS ABI] Give __attribute__((overloadable)) functions pretty names It turns out that there is a mangling for 'extern "C"', it's only used by MSVC in /clr mode. Co-opt this mangling so that extern "C" functions marked overloadable get demangled nicely. llvm-svn: 237548
2015-05-18 08:05:29 +08:00
// We would like to mangle all extern "C" functions using this additional
// component but this would break compatibility with MSVC's behavior.
// Instead, do this when we know that compatibility isn't important (in
// other words, when it is an overloaded extern "C" funciton).
if (FD->isExternC() && FD->hasAttr<OverloadableAttr>())
Out << "$$J0";
[-cxx-abi microsoft] Mangle declarations inside extern "C" 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
2013-09-13 17:03:14 +08:00
mangleFunctionClass(FD);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
Simplify MicrosoftCXXNameMangler::mangleFunctionType llvm-svn: 191950
2013-10-04 19:25:05 +08:00
mangleFunctionType(FT, FD);
[MS ABI] Function encodings are always encoded in template arguments llvm-svn: 237547
2015-05-18 08:05:25 +08:00
} else {
[-cxx-abi microsoft] Mangle declarations inside extern "C" 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
2013-09-13 17:03:14 +08:00
Out << '9';
[MS ABI] Function encodings are always encoded in template arguments llvm-svn: 237547
2015-05-18 08:05:25 +08:00
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
void MicrosoftCXXNameMangler::mangleVariableEncoding(const VarDecl *VD) {
// <type-encoding> ::= <storage-class> <variable-type>
// <storage-class> ::= 0 # private static member
// ::= 1 # protected static member
// ::= 2 # public static member
// ::= 3 # global
// ::= 4 # static local
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// The first character in the encoding (after the name) is the storage class.
if (VD->isStaticDataMember()) {
// If it's a static member, it also encodes the access level.
switch (VD->getAccess()) {
default:
case AS_private: Out << '0'; break;
case AS_protected: Out << '1'; break;
case AS_public: Out << '2'; break;
}
}
else if (!VD->isStaticLocal())
Out << '3';
else
Out << '4';
// Now mangle the type.
// <variable-type> ::= <type> <cvr-qualifiers>
// ::= <type> <pointee-cvr-qualifiers> # pointers, references
// Pointers and references are odd. The type of 'int * const foo;' gets
// mangled as 'QAHA' instead of 'PAHB', for example.
Don't go through the TypeSourceInfo when getting the SourceRange. VarDecl provides a method getSourceRange(), which provides a more robust way of getting the SourceRange since the TypeSourceInfo can be null in certain cases. Reviewed by: majnemer Differential Revision: http://reviews.llvm.org/D4281 llvm-svn: 211667
2014-06-25 13:37:25 +08:00
SourceRange SR = VD->getSourceRange();
MSVC ABI: Support C++11's auto on variables 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
2014-01-22 04:33:36 +08:00
QualType Ty = VD->getType();
[-cxx-abi microsoft] Mangle member pointers better Summary: There were several things going wrong: - We mangled in useless qualifiers like "volatile void" return types. - We didn't propagate 64-bit pointer markers sufficiently. - We mangled qualifiers belonging to the pointee incorrectly. This fixes PR16844 and PR16848. Reviewers: rnk, whunt Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1353 llvm-svn: 188450
2013-08-15 16:13:23 +08:00
if (Ty->isPointerType() || Ty->isReferenceType() ||
Ty->isMemberPointerType()) {
Don't go through the TypeSourceInfo when getting the SourceRange. VarDecl provides a method getSourceRange(), which provides a more robust way of getting the SourceRange since the TypeSourceInfo can be null in certain cases. Reviewed by: majnemer Differential Revision: http://reviews.llvm.org/D4281 llvm-svn: 211667
2014-06-25 13:37:25 +08:00
mangleType(Ty, SR, QMM_Drop);
MS ABI: Refactor extended qualifiers 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
2014-02-18 22:20:10 +08:00
manglePointerExtQualifiers(
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Ty.getDesugaredType(getASTContext()).getLocalQualifiers(), QualType());
[-cxx-abi microsoft] Mangle member pointers better Summary: There were several things going wrong: - We mangled in useless qualifiers like "volatile void" return types. - We didn't propagate 64-bit pointer markers sufficiently. - We mangled qualifiers belonging to the pointee incorrectly. This fixes PR16844 and PR16848. Reviewers: rnk, whunt Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1353 llvm-svn: 188450
2013-08-15 16:13:23 +08:00
if (const MemberPointerType *MPT = Ty->getAs<MemberPointerType>()) {
mangleQualifiers(MPT->getPointeeType().getQualifiers(), true);
// Member pointers are suffixed with a back reference to the member
// pointer's class name.
mangleName(MPT->getClass()->getAsCXXRecordDecl());
} else
mangleQualifiers(Ty->getPointeeType().getQualifiers(), false);
Revert "[-cxx-abi microsoft] Mangle UUIDs correctly, stick them in the proper section" This commit reverts r188053. It is breaking the build bots. llvm-svn: 188055
2013-08-09 13:56:24 +08:00
} else if (const ArrayType *AT = getASTContext().getAsArrayType(Ty)) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// Global arrays are funny, too.
[-cxx-abi microsoft] Canonicalize array parameters better 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
2013-09-11 12:44:30 +08:00
mangleDecayedArrayType(AT);
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
if (AT->getElementType()->isArrayType())
Out << 'A';
else
mangleQualifiers(Ty.getQualifiers(), false);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
} else {
Don't go through the TypeSourceInfo when getting the SourceRange. VarDecl provides a method getSourceRange(), which provides a more robust way of getting the SourceRange since the TypeSourceInfo can be null in certain cases. Reviewed by: majnemer Differential Revision: http://reviews.llvm.org/D4281 llvm-svn: 211667
2014-06-25 13:37:25 +08:00
mangleType(Ty, SR, QMM_Drop);
MS ABI: Correctly mangle CV qualifiers from typedefs llvm-svn: 221344
2014-11-05 21:54:21 +08:00
mangleQualifiers(Ty.getQualifiers(), false);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
}
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
void MicrosoftCXXNameMangler::mangleMemberDataPointer(const CXXRecordDecl *RD,
MS ABI: Handle indirect field decls in template args Properly support fields that come from anonymous unions and structs when used as template arguments for pointer to data member params. llvm-svn: 200921
2014-02-06 20:46:52 +08:00
const ValueDecl *VD) {
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
// <member-data-pointer> ::= <integer-literal>
// ::= $F <number> <number>
// ::= $G <number> <number> <number>
MS ABI: Tweak pointer-to-member mangling/inheritance model selection 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
2014-02-06 18:59:19 +08:00
int64_t FieldOffset;
int64_t VBTableOffset;
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
MSInheritanceAttr::Spelling IM = RD->getMSInheritanceModel();
MS ABI: Handle indirect field decls in template args Properly support fields that come from anonymous unions and structs when used as template arguments for pointer to data member params. llvm-svn: 200921
2014-02-06 20:46:52 +08:00
if (VD) {
FieldOffset = getASTContext().getFieldOffset(VD);
MS ABI: Tweak pointer-to-member mangling/inheritance model selection 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
2014-02-06 18:59:19 +08:00
assert(FieldOffset % getASTContext().getCharWidth() == 0 &&
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
"cannot take address of bitfield");
MS ABI: Tweak pointer-to-member mangling/inheritance model selection 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
2014-02-06 18:59:19 +08:00
FieldOffset /= getASTContext().getCharWidth();
VBTableOffset = 0;
[MS ABI] Account for the virtual inheritance quirk when mangling Virtual inheritance member pointers are always relative to the vbindex, even when the member pointer doesn't point into a virtual base. This is corrected by adjusting the non-virtual offset backwards from the vbptr back to the top of the most derived class. While we performed this adjustment when manifesting member pointers as constants or when performing conversions, we didn't perform the adjustment when mangling them. llvm-svn: 240453
2015-06-24 04:34:18 +08:00
if (IM == MSInheritanceAttr::Keyword_virtual_inheritance)
FieldOffset -= getASTContext().getOffsetOfBaseWithVBPtr(RD).getQuantity();
MS ABI: Tweak pointer-to-member mangling/inheritance model selection 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
2014-02-06 18:59:19 +08:00
} else {
FieldOffset = RD->nullFieldOffsetIsZero() ? 0 : -1;
VBTableOffset = -1;
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
}
MS ABI: Tweak pointer-to-member mangling/inheritance model selection 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
2014-02-06 18:59:19 +08:00
char Code = '\0';
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
switch (IM) {
MS ABI: Tweak pointer-to-member mangling/inheritance model selection 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
2014-02-06 18:59:19 +08:00
case MSInheritanceAttr::Keyword_single_inheritance: Code = '0'; break;
case MSInheritanceAttr::Keyword_multiple_inheritance: Code = '0'; break;
case MSInheritanceAttr::Keyword_virtual_inheritance: Code = 'F'; break;
case MSInheritanceAttr::Keyword_unspecified_inheritance: Code = 'G'; break;
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
}
MS ABI: Tweak pointer-to-member mangling/inheritance model selection 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
2014-02-06 18:59:19 +08:00
Out << '$' << Code;
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
MS ABI: Tweak pointer-to-member mangling/inheritance model selection 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
2014-02-06 18:59:19 +08:00
mangleNumber(FieldOffset);
Mangle the vbptr offset into pointers to member functions This can actually be non-zero if you override a function from a virtual base and you have forced the most_general pointer to member representation. llvm-svn: 205727
2014-04-08 02:07:03 +08:00
// The C++ standard doesn't allow base-to-derived member pointer conversions
// in template parameter contexts, so the vbptr offset of data member pointers
// is always zero.
MS ABI: Tweak pointer-to-member mangling/inheritance model selection 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
2014-02-06 18:59:19 +08:00
if (MSInheritanceAttr::hasVBPtrOffsetField(IM))
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
mangleNumber(0);
MS ABI: Tweak pointer-to-member mangling/inheritance model selection 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
2014-02-06 18:59:19 +08:00
if (MSInheritanceAttr::hasVBTableOffsetField(IM))
mangleNumber(VBTableOffset);
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
}
void
MicrosoftCXXNameMangler::mangleMemberFunctionPointer(const CXXRecordDecl *RD,
const CXXMethodDecl *MD) {
// <member-function-pointer> ::= $1? <name>
// ::= $H? <name> <number>
// ::= $I? <name> <number> <number>
// ::= $J? <name> <number> <number> <number>
MSInheritanceAttr::Spelling IM = RD->getMSInheritanceModel();
char Code = '\0';
switch (IM) {
case MSInheritanceAttr::Keyword_single_inheritance: Code = '1'; break;
case MSInheritanceAttr::Keyword_multiple_inheritance: Code = 'H'; break;
case MSInheritanceAttr::Keyword_virtual_inheritance: Code = 'I'; break;
case MSInheritanceAttr::Keyword_unspecified_inheritance: Code = 'J'; break;
}
// If non-virtual, mangle the name. If virtual, mangle as a virtual memptr
// thunk.
uint64_t NVOffset = 0;
uint64_t VBTableOffset = 0;
Mangle the vbptr offset into pointers to member functions This can actually be non-zero if you override a function from a virtual base and you have forced the most_general pointer to member representation. llvm-svn: 205727
2014-04-08 02:07:03 +08:00
uint64_t VBPtrOffset = 0;
MS ABI: Mangle null pointer-to-member-functions compatibly Summary: Previously, we would mangle nullptr pointer-to-member-functions in class templates with a mangling we invented because contemporary versions of MSVC would crash when trying to compile such code. However, VS "14" can successfully compile these sorts of template instantiations. This commit updates our mangling to be compatible with theirs. Reviewers: rnk Reviewed By: rnk Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D4059 llvm-svn: 210637
2014-06-11 12:55:08 +08:00
if (MD) {
Out << '$' << Code << '?';
if (MD->isVirtual()) {
MicrosoftVTableContext *VTContext =
cast<MicrosoftVTableContext>(getASTContext().getVTableContext());
const MicrosoftVTableContext::MethodVFTableLocation &ML =
VTContext->getMethodVFTableLocation(GlobalDecl(MD));
mangleVirtualMemPtrThunk(MD, ML);
NVOffset = ML.VFPtrOffset.getQuantity();
VBTableOffset = ML.VBTableIndex * 4;
if (ML.VBase) {
const ASTRecordLayout &Layout = getASTContext().getASTRecordLayout(RD);
VBPtrOffset = Layout.getVBPtrOffset().getQuantity();
}
} else {
mangleName(MD);
[MS ABI] Function encodings are always encoded in template arguments llvm-svn: 237547
2015-05-18 08:05:25 +08:00
mangleFunctionEncoding(MD, /*ShouldMangle=*/true);
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
}
[MS ABI] Account for the virtual inheritance quirk when mangling Virtual inheritance member pointers are always relative to the vbindex, even when the member pointer doesn't point into a virtual base. This is corrected by adjusting the non-virtual offset backwards from the vbptr back to the top of the most derived class. While we performed this adjustment when manifesting member pointers as constants or when performing conversions, we didn't perform the adjustment when mangling them. llvm-svn: 240453
2015-06-24 04:34:18 +08:00
if (VBTableOffset == 0 &&
IM == MSInheritanceAttr::Keyword_virtual_inheritance)
NVOffset -= getASTContext().getOffsetOfBaseWithVBPtr(RD).getQuantity();
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
} else {
MS ABI: Mangle null pointer-to-member-functions compatibly Summary: Previously, we would mangle nullptr pointer-to-member-functions in class templates with a mangling we invented because contemporary versions of MSVC would crash when trying to compile such code. However, VS "14" can successfully compile these sorts of template instantiations. This commit updates our mangling to be compatible with theirs. Reviewers: rnk Reviewed By: rnk Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D4059 llvm-svn: 210637
2014-06-11 12:55:08 +08:00
// Null single inheritance member functions are encoded as a simple nullptr.
if (IM == MSInheritanceAttr::Keyword_single_inheritance) {
Out << "$0A@";
return;
}
if (IM == MSInheritanceAttr::Keyword_unspecified_inheritance)
VBTableOffset = -1;
Out << '$' << Code;
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
}
if (MSInheritanceAttr::hasNVOffsetField(/*IsMemberFunction=*/true, IM))
[MS ABI] Account for the virtual inheritance quirk when mangling Virtual inheritance member pointers are always relative to the vbindex, even when the member pointer doesn't point into a virtual base. This is corrected by adjusting the non-virtual offset backwards from the vbptr back to the top of the most derived class. While we performed this adjustment when manifesting member pointers as constants or when performing conversions, we didn't perform the adjustment when mangling them. llvm-svn: 240453
2015-06-24 04:34:18 +08:00
mangleNumber(static_cast<uint32_t>(NVOffset));
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
if (MSInheritanceAttr::hasVBPtrOffsetField(IM))
Mangle the vbptr offset into pointers to member functions This can actually be non-zero if you override a function from a virtual base and you have forced the most_general pointer to member representation. llvm-svn: 205727
2014-04-08 02:07:03 +08:00
mangleNumber(VBPtrOffset);
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
if (MSInheritanceAttr::hasVBTableOffsetField(IM))
mangleNumber(VBTableOffset);
}
void MicrosoftCXXNameMangler::mangleVirtualMemPtrThunk(
const CXXMethodDecl *MD,
const MicrosoftVTableContext::MethodVFTableLocation &ML) {
// Get the vftable offset.
CharUnits PointerWidth = getASTContext().toCharUnitsFromBits(
getASTContext().getTargetInfo().getPointerWidth(0));
uint64_t OffsetInVFTable = ML.Index * PointerWidth.getQuantity();
Out << "?_9";
mangleName(MD->getParent());
Out << "$B";
mangleNumber(OffsetInVFTable);
Out << 'A';
MS ABI: Mangle virtual member pointer thunks with the correct CC Virtual member pointers are implemented using a thunk. We assumed that the calling convention for this thunk was always __thiscall for 32-bit targets and __cdecl for 64-bit targets. However, this is not the case. Mangle in whichever calling convention is appropriate for this member function thunk. llvm-svn: 232254
2015-03-14 14:34:41 +08:00
mangleCallingConvention(MD->getType()->getAs<FunctionProtoType>());
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void MicrosoftCXXNameMangler::mangleName(const NamedDecl *ND) {
// <name> ::= <unscoped-name> {[<named-scope>]+ | [<nested-name>]}? @
// Always start with the unqualified name.
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
mangleUnqualifiedName(ND);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
mangleNestedName(ND);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// Terminate the whole name with an '@'.
Out << '@';
}
[-cxx-abi microsoft] Mangle large integral constants correctly 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
2013-12-09 18:44:32 +08:00
void MicrosoftCXXNameMangler::mangleNumber(int64_t Number) {
// <non-negative integer> ::= A@ # when Number == 0
// ::= <decimal digit> # when 1 <= Number <= 10
// ::= <hex digit>+ @ # when Number >= 10
//
// <number> ::= [?] <non-negative integer>
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
[-cxx-abi microsoft] Mangle large integral constants correctly 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
2013-12-09 18:44:32 +08:00
uint64_t Value = static_cast<uint64_t>(Number);
if (Number < 0) {
Value = -Value;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
Out << '?';
}
[-cxx-abi microsoft] Mangle large integral constants correctly 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
2013-12-09 18:44:32 +08:00
if (Value == 0)
Out << "A@";
else if (Value >= 1 && Value <= 10)
Out << (Value - 1);
else {
// Numbers that are not encoded as decimal digits are represented as nibbles
// in the range of ASCII characters 'A' to 'P'.
// The number 0x123450 would be encoded as 'BCDEFA'
char EncodedNumberBuffer[sizeof(uint64_t) * 2];
Import MutableArrayRef into clang namespace. llvm-svn: 211988
2014-06-29 07:22:33 +08:00
MutableArrayRef<char> BufferRef(EncodedNumberBuffer);
MutableArrayRef<char>::reverse_iterator I = BufferRef.rbegin();
[-cxx-abi microsoft] Mangle large integral constants correctly 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
2013-12-09 18:44:32 +08:00
for (; Value != 0; Value >>= 4)
*I++ = 'A' + (Value & 0xf);
Out.write(I.base(), I - BufferRef.rbegin());
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
Out << '@';
}
}
static const TemplateDecl *
[ms-cxxabi] Fix assertion on unhandled function template arg types This code was changed in r158376 to get template argument source info for better diagnostics, but the current code asserts for any kind of unsupported template argument before it can issue a diagnostic. This change goes back to the Itanium implementation of isTemplate() and puts the argument index into the diagnostic instead of a source location. Review URL: http://llvm-reviews.chandlerc.com/D553 llvm-svn: 177471
2013-03-20 09:40:23 +08:00
isTemplate(const NamedDecl *ND, const TemplateArgumentList *&TemplateArgs) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// Check if we have a function template.
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
if (const FunctionDecl *FD = dyn_cast<FunctionDecl>(ND)) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
if (const TemplateDecl *TD = FD->getPrimaryTemplate()) {
[ms-cxxabi] Fix assertion on unhandled function template arg types This code was changed in r158376 to get template argument source info for better diagnostics, but the current code asserts for any kind of unsupported template argument before it can issue a diagnostic. This change goes back to the Itanium implementation of isTemplate() and puts the argument index into the diagnostic instead of a source location. Review URL: http://llvm-reviews.chandlerc.com/D553 llvm-svn: 177471
2013-03-20 09:40:23 +08:00
TemplateArgs = FD->getTemplateSpecializationArgs();
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
return TD;
}
}
// Check if we have a class template.
if (const ClassTemplateSpecializationDecl *Spec =
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
dyn_cast<ClassTemplateSpecializationDecl>(ND)) {
[ms-cxxabi] Fix assertion on unhandled function template arg types This code was changed in r158376 to get template argument source info for better diagnostics, but the current code asserts for any kind of unsupported template argument before it can issue a diagnostic. This change goes back to the Itanium implementation of isTemplate() and puts the argument index into the diagnostic instead of a source location. Review URL: http://llvm-reviews.chandlerc.com/D553 llvm-svn: 177471
2013-03-20 09:40:23 +08:00
TemplateArgs = &Spec->getTemplateArgs();
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
return Spec->getSpecializedTemplate();
}
MS ABI: Mangle variable templates properly 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
2014-03-04 13:38:05 +08:00
// Check if we have a variable template.
if (const VarTemplateSpecializationDecl *Spec =
dyn_cast<VarTemplateSpecializationDecl>(ND)) {
TemplateArgs = &Spec->getTemplateArgs();
return Spec->getSpecializedTemplate();
}
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
return nullptr;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
void MicrosoftCXXNameMangler::mangleUnqualifiedName(const NamedDecl *ND,
DeclarationName Name) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// <unqualified-name> ::= <operator-name>
// ::= <ctor-dtor-name>
// ::= <source-name>
// ::= <template-name>
[ms-cxxabi] Fix assertion on unhandled function template arg types This code was changed in r158376 to get template argument source info for better diagnostics, but the current code asserts for any kind of unsupported template argument before it can issue a diagnostic. This change goes back to the Itanium implementation of isTemplate() and puts the argument index into the diagnostic instead of a source location. Review URL: http://llvm-reviews.chandlerc.com/D553 llvm-svn: 177471
2013-03-20 09:40:23 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// Check if we have a template.
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
const TemplateArgumentList *TemplateArgs = nullptr;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
if (const TemplateDecl *TD = isTemplate(ND, TemplateArgs)) {
[ms-cxxabi] Don't consider function templates for name backrefs They don't seem to be used for back references, presumably because a function template is unlikely to reoccur, while a class template name may reoccur as a type. This fixes a mangling issue for llvm::hash_combine() in Hashing.h. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D1078 llvm-svn: 186233
2013-07-13 08:43:39 +08:00
// Function templates aren't considered for name back referencing. This
// makes sense since function templates aren't likely to occur multiple
// times in a symbol.
// FIXME: Test alias template mangling with MSVC 2013.
if (!isa<ClassTemplateDecl>(TD)) {
mangleTemplateInstantiationName(TD, *TemplateArgs);
Avoid extra back reference key lookup in msmangler Avoid a second key lookup when the back reference key is going to be inserted in the StringMap. The string lookups in the msmangler are the main responsible for the huge overhead when compared to the itanium mangler. This patch makes a small but noticeable improvement. Reviewed by: rnk Differential Revision: http://reviews.llvm.org/D4130 Patch by Agustín Bergé! llvm-svn: 211813
2014-06-27 06:42:18 +08:00
Out << '@';
[ms-cxxabi] Don't consider function templates for name backrefs They don't seem to be used for back references, presumably because a function template is unlikely to reoccur, while a class template name may reoccur as a type. This fixes a mangling issue for llvm::hash_combine() in Hashing.h. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D1078 llvm-svn: 186233
2013-07-13 08:43:39 +08:00
return;
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// Here comes the tricky thing: if we need to mangle something like
// void foo(A::X<Y>, B::X<Y>),
// the X<Y> part is aliased. However, if you need to mangle
// void foo(A::X<A::Y>, A::X<B::Y>),
// the A::X<> part is not aliased.
// That said, from the mangler's perspective we have a structure like this:
// namespace[s] -> type[ -> template-parameters]
// but from the Clang perspective we have
// type [ -> template-parameters]
// \-> namespace[s]
// What we do is we create a new mangler, mangle the same type (without
MS ABI: Simplify microsoft mangling of template instantiations Use mangled template instantiation name as key for back references. Templates have their own context for back references, so their mangling is always the same regardless of context. This avoids mangling template instantiations twice. Patch by Agustín Bergé! llvm-svn: 210416
2014-06-08 12:51:13 +08:00
// a namespace suffix) to a string using the extra mangler and then use
// the mangled type name as a key to check the mangling of different types
// for aliasing.
Avoid extra back reference key lookup in msmangler Avoid a second key lookup when the back reference key is going to be inserted in the StringMap. The string lookups in the msmangler are the main responsible for the huge overhead when compared to the itanium mangler. This patch makes a small but noticeable improvement. Reviewed by: rnk Differential Revision: http://reviews.llvm.org/D4130 Patch by Agustín Bergé! llvm-svn: 211813
2014-06-27 06:42:18 +08:00
llvm::SmallString<64> TemplateMangling;
llvm::raw_svector_ostream Stream(TemplateMangling);
MS ABI: Simplify microsoft mangling of template instantiations Use mangled template instantiation name as key for back references. Templates have their own context for back references, so their mangling is always the same regardless of context. This avoids mangling template instantiations twice. Patch by Agustín Bergé! llvm-svn: 210416
2014-06-08 12:51:13 +08:00
MicrosoftCXXNameMangler Extra(Context, Stream);
Extra.mangleTemplateInstantiationName(TD, *TemplateArgs);
Avoid extra back reference key lookup in msmangler Avoid a second key lookup when the back reference key is going to be inserted in the StringMap. The string lookups in the msmangler are the main responsible for the huge overhead when compared to the itanium mangler. This patch makes a small but noticeable improvement. Reviewed by: rnk Differential Revision: http://reviews.llvm.org/D4130 Patch by Agustín Bergé! llvm-svn: 211813
2014-06-27 06:42:18 +08:00
mangleSourceName(TemplateMangling);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
return;
}
switch (Name.getNameKind()) {
case DeclarationName::Identifier: {
if (const IdentifierInfo *II = Name.getAsIdentifierInfo()) {
[-cxx-abi microsoft] Create backrefs for <unnamed-type-`id'> 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
2013-11-26 01:50:19 +08:00
mangleSourceName(II->getName());
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
break;
}
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// Otherwise, an anonymous entity. We must have a declaration.
assert(ND && "mangling empty name without declaration");
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
if (const NamespaceDecl *NS = dyn_cast<NamespaceDecl>(ND)) {
if (NS->isAnonymousNamespace()) {
Out << "?A@";
break;
}
}
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
if (const VarDecl *VD = dyn_cast<VarDecl>(ND)) {
// We must have an anonymous union or struct declaration.
const CXXRecordDecl *RD = VD->getType()->getAsCXXRecordDecl();
assert(RD && "expected variable decl to have a record type");
// Anonymous types with no tag or typedef get the name of their
// declarator mangled in. If they have no declarator, number them with
// a $S prefix.
llvm::SmallString<64> Name("$S");
// Get a unique id for the anonymous struct.
Name += llvm::utostr(Context.getAnonymousStructId(RD) + 1);
mangleSourceName(Name.str());
break;
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// We must have an anonymous struct.
const TagDecl *TD = cast<TagDecl>(ND);
if (const TypedefNameDecl *D = TD->getTypedefNameForAnonDecl()) {
assert(TD->getDeclContext() == D->getDeclContext() &&
"Typedef should not be in another decl context!");
assert(D->getDeclName().getAsIdentifierInfo() &&
"Typedef was not named!");
[-cxx-abi microsoft] Create backrefs for <unnamed-type-`id'> 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
2013-11-26 01:50:19 +08:00
mangleSourceName(D->getDeclName().getAsIdentifierInfo()->getName());
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
break;
}
MS ABI: Mangle lambdas 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
2014-03-05 18:35:06 +08:00
if (const CXXRecordDecl *Record = dyn_cast<CXXRecordDecl>(TD)) {
if (Record->isLambda()) {
llvm::SmallString<10> Name("<lambda_");
unsigned LambdaId;
if (Record->getLambdaManglingNumber())
LambdaId = Record->getLambdaManglingNumber();
else
LambdaId = Context.getLambdaId(Record);
Name += llvm::utostr(LambdaId);
Name += ">";
mangleSourceName(Name);
break;
}
}
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
llvm::SmallString<64> Name("<unnamed-type-");
[MS ABI] Correctly mangle classes without names for linkage purposes A class without a name for linkage purposes gets a name along the lines of <unnamed-type-foo> where foo is either the name of a declarator which defined it (like a variable or field) or a typedef-name (like a typedef or alias-declaration). We handled the declarator case correctly but it would fall down during template instantiation if the declarator didn't share the tag's type. We failed to handle the typedef-name case at all. Instead, keep track of the association between the two and keep it up to date in the face of template instantiation. llvm-svn: 246469
2015-09-01 02:48:39 +08:00
if (DeclaratorDecl *DD =
Context.getASTContext().getDeclaratorForUnnamedTagDecl(TD)) {
// Anonymous types without a name for linkage purposes have their
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
// declarator mangled in if they have one.
[MS ABI] Correctly mangle classes without names for linkage purposes A class without a name for linkage purposes gets a name along the lines of <unnamed-type-foo> where foo is either the name of a declarator which defined it (like a variable or field) or a typedef-name (like a typedef or alias-declaration). We handled the declarator case correctly but it would fall down during template instantiation if the declarator didn't share the tag's type. We failed to handle the typedef-name case at all. Instead, keep track of the association between the two and keep it up to date in the face of template instantiation. llvm-svn: 246469
2015-09-01 02:48:39 +08:00
Name += DD->getName();
} else if (TypedefNameDecl *TND =
Context.getASTContext().getTypedefNameForUnnamedTagDecl(
TD)) {
// Anonymous types without a name for linkage purposes have their
// associate typedef mangled in if they have one.
Name += TND->getName();
[-cxx-abi microsoft] Create backrefs for <unnamed-type-`id'> 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
2013-11-26 01:50:19 +08:00
} else {
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
// Otherwise, number the types using a $S prefix.
Name += "$S";
MS ABI: Mangle lambdas 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
2014-03-05 18:35:06 +08:00
Name += llvm::utostr(Context.getAnonymousStructId(TD));
[-cxx-abi microsoft] Create backrefs for <unnamed-type-`id'> 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
2013-11-26 01:50:19 +08:00
}
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
Name += ">";
mangleSourceName(Name.str());
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
break;
}
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case DeclarationName::ObjCZeroArgSelector:
case DeclarationName::ObjCOneArgSelector:
case DeclarationName::ObjCMultiArgSelector:
llvm_unreachable("Can't mangle Objective-C selector names here!");
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case DeclarationName::CXXConstructorName:
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
if (Structor == getStructor(ND)) {
if (StructorType == Ctor_CopyingClosure) {
Out << "?_O";
return;
}
if (StructorType == Ctor_DefaultClosure) {
Out << "?_F";
return;
}
Better support for constructors with -cxx-abi microsoft, partly fixes PR12784 llvm-svn: 176186
2013-02-27 21:46:31 +08:00
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
Out << "?0";
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
return;
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case DeclarationName::CXXDestructorName:
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
if (ND == Structor)
// If the named decl is the C++ destructor we're mangling,
// use the type we were given.
mangleCXXDtorType(static_cast<CXXDtorType>(StructorType));
else
[ms-cxxabi] Emit linkonce complete dtors in TUs that need them Based on Peter Collingbourne's destructor patches. Prior to this change, clang was considering ?1 to be the complete destructor and the base destructor, which was wrong. This lead to crashes when clang tried to emit two LLVM functions with the same name. In this ABI, TUs with non-inline dtors might not emit a complete destructor. They are emitted as inline thunks in TUs that need them, and they always delegate to the base dtors of the complete class and its virtual bases. This change uses the DeferredDecls machinery to emit complete dtors as needed. Currently in clang try body destructors can catch exceptions thrown by virtual base destructors. In the Microsoft C++ ABI, clang may not have the destructor definition, in which case clang won't wrap the virtual virtual base destructor calls in a try-catch. Diagnosing this in user code is TODO. Finally, for classes that don't use virtual inheritance, MSVC always calls the base destructor (?1) directly. This is a useful code size optimization that avoids emitting lots of extra thunks or aliases. Implementing it also means our existing tests continue to pass, and is consistent with MSVC's output. We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but it will require further testing. Reviewers: rjmccall CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1066 llvm-svn: 186828
2013-07-22 21:51:44 +08:00
// Otherwise, use the base destructor name. This is relevant if a
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
// class with a destructor is declared within a destructor.
[ms-cxxabi] Emit linkonce complete dtors in TUs that need them Based on Peter Collingbourne's destructor patches. Prior to this change, clang was considering ?1 to be the complete destructor and the base destructor, which was wrong. This lead to crashes when clang tried to emit two LLVM functions with the same name. In this ABI, TUs with non-inline dtors might not emit a complete destructor. They are emitted as inline thunks in TUs that need them, and they always delegate to the base dtors of the complete class and its virtual bases. This change uses the DeferredDecls machinery to emit complete dtors as needed. Currently in clang try body destructors can catch exceptions thrown by virtual base destructors. In the Microsoft C++ ABI, clang may not have the destructor definition, in which case clang won't wrap the virtual virtual base destructor calls in a try-catch. Diagnosing this in user code is TODO. Finally, for classes that don't use virtual inheritance, MSVC always calls the base destructor (?1) directly. This is a useful code size optimization that avoids emitting lots of extra thunks or aliases. Implementing it also means our existing tests continue to pass, and is consistent with MSVC's output. We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but it will require further testing. Reviewers: rjmccall CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1066 llvm-svn: 186828
2013-07-22 21:51:44 +08:00
mangleCXXDtorType(Dtor_Base);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
break;
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case DeclarationName::CXXConversionFunctionName:
// <operator-name> ::= ?B # (cast)
// The target type is encoded as the return type.
Out << "?B";
break;
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case DeclarationName::CXXOperatorName:
mangleOperatorName(Name.getCXXOverloadedOperator(), ND->getLocation());
break;
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case DeclarationName::CXXLiteralOperatorName: {
MS-ABI: Implement user defined literals Straightforward implementation of UDLs, it's compatible with VS "14". This nearly completes our implementation of C++ name mangling for the MS-ABI. llvm-svn: 210197
2014-06-05 00:46:26 +08:00
Out << "?__K";
mangleSourceName(Name.getCXXLiteralIdentifier()->getName());
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
break;
}
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case DeclarationName::CXXUsingDirective:
llvm_unreachable("Can't mangle a using directive name!");
}
}
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
void MicrosoftCXXNameMangler::mangleNestedName(const NamedDecl *ND) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// <postfix> ::= <unqualified-name> [<postfix>]
// ::= <substitution> [<postfix>]
MS ABI: Mangle lambdas which are given the same mangling number It is possible for lambdas to get the same mangling number because they may exist in different mangling contexts. To handle this correctly, mangle the context into the name as well. llvm-svn: 214947
2014-08-06 11:12:47 +08:00
const DeclContext *DC = getEffectiveDeclContext(ND);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
while (!DC->isTranslationUnit()) {
if (isa<TagDecl>(ND) || isa<VarDecl>(ND)) {
unsigned Disc;
if (Context.getNextDiscriminator(ND, Disc)) {
Out << '?';
mangleNumber(Disc);
Out << '?';
}
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
if (const BlockDecl *BD = dyn_cast<BlockDecl>(DC)) {
Make DiagnosticsEngine non-copyable Also provide an out-of-line dtor for CompilerInvocation. Cleanup work that may help reduce header inclusion for IntrusiveRefCntPtr. llvm-svn: 208512
2014-05-12 06:10:52 +08:00
DiagnosticsEngine &Diags = Context.getDiags();
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
unsigned DiagID =
Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle a local inside this block yet");
Diags.Report(BD->getLocation(), DiagID);
// FIXME: This is completely, utterly, wrong; see ItaniumMangle
// for how this should be done.
Out << "__block_invoke" << Context.getBlockId(BD, false);
Out << '@';
continue;
} else if (const ObjCMethodDecl *Method = dyn_cast<ObjCMethodDecl>(DC)) {
mangleObjCMethodName(Method);
} else if (isa<NamedDecl>(DC)) {
ND = cast<NamedDecl>(DC);
if (const FunctionDecl *FD = dyn_cast<FunctionDecl>(ND)) {
mangle(FD, "?");
break;
} else
mangleUnqualifiedName(ND);
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
DC = DC->getParent();
}
}
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
void MicrosoftCXXNameMangler::mangleCXXDtorType(CXXDtorType T) {
[ms-cxxabi] Emit linkonce complete dtors in TUs that need them Based on Peter Collingbourne's destructor patches. Prior to this change, clang was considering ?1 to be the complete destructor and the base destructor, which was wrong. This lead to crashes when clang tried to emit two LLVM functions with the same name. In this ABI, TUs with non-inline dtors might not emit a complete destructor. They are emitted as inline thunks in TUs that need them, and they always delegate to the base dtors of the complete class and its virtual bases. This change uses the DeferredDecls machinery to emit complete dtors as needed. Currently in clang try body destructors can catch exceptions thrown by virtual base destructors. In the Microsoft C++ ABI, clang may not have the destructor definition, in which case clang won't wrap the virtual virtual base destructor calls in a try-catch. Diagnosing this in user code is TODO. Finally, for classes that don't use virtual inheritance, MSVC always calls the base destructor (?1) directly. This is a useful code size optimization that avoids emitting lots of extra thunks or aliases. Implementing it also means our existing tests continue to pass, and is consistent with MSVC's output. We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but it will require further testing. Reviewers: rjmccall CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1066 llvm-svn: 186828
2013-07-22 21:51:44 +08:00
// Microsoft uses the names on the case labels for these dtor variants. Clang
// uses the Itanium terminology internally. Everything in this ABI delegates
// towards the base dtor.
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
switch (T) {
[ms-cxxabi] Emit linkonce complete dtors in TUs that need them Based on Peter Collingbourne's destructor patches. Prior to this change, clang was considering ?1 to be the complete destructor and the base destructor, which was wrong. This lead to crashes when clang tried to emit two LLVM functions with the same name. In this ABI, TUs with non-inline dtors might not emit a complete destructor. They are emitted as inline thunks in TUs that need them, and they always delegate to the base dtors of the complete class and its virtual bases. This change uses the DeferredDecls machinery to emit complete dtors as needed. Currently in clang try body destructors can catch exceptions thrown by virtual base destructors. In the Microsoft C++ ABI, clang may not have the destructor definition, in which case clang won't wrap the virtual virtual base destructor calls in a try-catch. Diagnosing this in user code is TODO. Finally, for classes that don't use virtual inheritance, MSVC always calls the base destructor (?1) directly. This is a useful code size optimization that avoids emitting lots of extra thunks or aliases. Implementing it also means our existing tests continue to pass, and is consistent with MSVC's output. We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but it will require further testing. Reviewers: rjmccall CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1066 llvm-svn: 186828
2013-07-22 21:51:44 +08:00
// <operator-name> ::= ?1 # destructor
case Dtor_Base: Out << "?1"; return;
// <operator-name> ::= ?_D # vbase destructor
case Dtor_Complete: Out << "?_D"; return;
// <operator-name> ::= ?_G # scalar deleting destructor
case Dtor_Deleting: Out << "?_G"; return;
// <operator-name> ::= ?_E # vector deleting destructor
// FIXME: Add a vector deleting dtor type. It goes in the vtable, so we need
// it.
Add support for putting constructors and destructos in explicit comdats. There are situations when clang knows that the C1 and C2 constructors or the D1 and D2 destructors are identical. We already optimize some of these cases, but cannot optimize it when the GlobalValue is weak_odr. The problem with weak_odr is that an old TU seeing the same code will have a C1 and a C2 comdat with the corresponding symbols. We cannot suddenly start putting the C2 symbol in the C1 comdat as we cannot guarantee that the linker will not pick a .o with only C1 in it. The solution implemented by GCC is to expand the ABI to have a comdat whose name uses a C5/D5 suffix and always has both symbols. That is what this patch implements. llvm-svn: 217874
2014-09-16 23:18:21 +08:00
case Dtor_Comdat:
llvm_unreachable("not expecting a COMDAT");
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
}
llvm_unreachable("Unsupported dtor type?");
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void MicrosoftCXXNameMangler::mangleOperatorName(OverloadedOperatorKind OO,
SourceLocation Loc) {
switch (OO) {
// ?0 # constructor
// ?1 # destructor
// <operator-name> ::= ?2 # new
case OO_New: Out << "?2"; break;
// <operator-name> ::= ?3 # delete
case OO_Delete: Out << "?3"; break;
// <operator-name> ::= ?4 # =
case OO_Equal: Out << "?4"; break;
// <operator-name> ::= ?5 # >>
case OO_GreaterGreater: Out << "?5"; break;
// <operator-name> ::= ?6 # <<
case OO_LessLess: Out << "?6"; break;
// <operator-name> ::= ?7 # !
case OO_Exclaim: Out << "?7"; break;
// <operator-name> ::= ?8 # ==
case OO_EqualEqual: Out << "?8"; break;
// <operator-name> ::= ?9 # !=
case OO_ExclaimEqual: Out << "?9"; break;
// <operator-name> ::= ?A # []
case OO_Subscript: Out << "?A"; break;
// ?B # conversion
// <operator-name> ::= ?C # ->
case OO_Arrow: Out << "?C"; break;
// <operator-name> ::= ?D # *
case OO_Star: Out << "?D"; break;
// <operator-name> ::= ?E # ++
case OO_PlusPlus: Out << "?E"; break;
// <operator-name> ::= ?F # --
case OO_MinusMinus: Out << "?F"; break;
// <operator-name> ::= ?G # -
case OO_Minus: Out << "?G"; break;
// <operator-name> ::= ?H # +
case OO_Plus: Out << "?H"; break;
// <operator-name> ::= ?I # &
case OO_Amp: Out << "?I"; break;
// <operator-name> ::= ?J # ->*
case OO_ArrowStar: Out << "?J"; break;
// <operator-name> ::= ?K # /
case OO_Slash: Out << "?K"; break;
// <operator-name> ::= ?L # %
case OO_Percent: Out << "?L"; break;
// <operator-name> ::= ?M # <
case OO_Less: Out << "?M"; break;
// <operator-name> ::= ?N # <=
case OO_LessEqual: Out << "?N"; break;
// <operator-name> ::= ?O # >
case OO_Greater: Out << "?O"; break;
// <operator-name> ::= ?P # >=
case OO_GreaterEqual: Out << "?P"; break;
// <operator-name> ::= ?Q # ,
case OO_Comma: Out << "?Q"; break;
// <operator-name> ::= ?R # ()
case OO_Call: Out << "?R"; break;
// <operator-name> ::= ?S # ~
case OO_Tilde: Out << "?S"; break;
// <operator-name> ::= ?T # ^
case OO_Caret: Out << "?T"; break;
// <operator-name> ::= ?U # |
case OO_Pipe: Out << "?U"; break;
// <operator-name> ::= ?V # &&
case OO_AmpAmp: Out << "?V"; break;
// <operator-name> ::= ?W # ||
case OO_PipePipe: Out << "?W"; break;
// <operator-name> ::= ?X # *=
case OO_StarEqual: Out << "?X"; break;
// <operator-name> ::= ?Y # +=
case OO_PlusEqual: Out << "?Y"; break;
// <operator-name> ::= ?Z # -=
case OO_MinusEqual: Out << "?Z"; break;
// <operator-name> ::= ?_0 # /=
case OO_SlashEqual: Out << "?_0"; break;
// <operator-name> ::= ?_1 # %=
case OO_PercentEqual: Out << "?_1"; break;
// <operator-name> ::= ?_2 # >>=
case OO_GreaterGreaterEqual: Out << "?_2"; break;
// <operator-name> ::= ?_3 # <<=
case OO_LessLessEqual: Out << "?_3"; break;
// <operator-name> ::= ?_4 # &=
case OO_AmpEqual: Out << "?_4"; break;
// <operator-name> ::= ?_5 # |=
case OO_PipeEqual: Out << "?_5"; break;
// <operator-name> ::= ?_6 # ^=
case OO_CaretEqual: Out << "?_6"; break;
// ?_7 # vftable
// ?_8 # vbtable
// ?_9 # vcall
// ?_A # typeof
// ?_B # local static guard
// ?_C # string
// ?_D # vbase destructor
// ?_E # vector deleting destructor
// ?_F # default constructor closure
// ?_G # scalar deleting destructor
// ?_H # vector constructor iterator
// ?_I # vector destructor iterator
// ?_J # vector vbase constructor iterator
// ?_K # virtual displacement map
// ?_L # eh vector constructor iterator
// ?_M # eh vector destructor iterator
// ?_N # eh vector vbase constructor iterator
// ?_O # copy constructor closure
// ?_P<name> # udt returning <name>
// ?_Q # <unknown>
// ?_R0 # RTTI Type Descriptor
// ?_R1 # RTTI Base Class Descriptor at (a,b,c,d)
// ?_R2 # RTTI Base Class Array
// ?_R3 # RTTI Class Hierarchy Descriptor
// ?_R4 # RTTI Complete Object Locator
// ?_S # local vftable
// ?_T # local vftable constructor closure
// <operator-name> ::= ?_U # new[]
case OO_Array_New: Out << "?_U"; break;
// <operator-name> ::= ?_V # delete[]
case OO_Array_Delete: Out << "?_V"; break;
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case OO_Conditional: {
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this conditional operator yet");
Diags.Report(Loc, DiagID);
break;
}
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case OO_None:
case NUM_OVERLOADED_OPERATORS:
llvm_unreachable("Not an overloaded operator");
}
}
[-cxx-abi microsoft] Create backrefs for <unnamed-type-`id'> 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
2013-11-26 01:50:19 +08:00
void MicrosoftCXXNameMangler::mangleSourceName(StringRef Name) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// <source name> ::= <identifier> @
MS ABI: Avoid hashing back reference keys in mangler This patch replaces the back reference StringMap from the MS mangler with a SmallVector of strings. My previous patches reduced the number of hashes involved in back reference lookups, this one removes them completely. The back reference map contains at most 10 entries, which are likely to be of varying sizes and different initial subsequences, and which can easily became huge (due to templates and namespaces). The solution presented is the simplest possible one. Nevertheless, it's enough to reduce compilation times for a particular test case from 11.1s to 9s, versus 8.58s for the Itanium ABI. Possible further improvements include using a sorted vector (carefully to not introduce an extra comparison), storing the string contents in a common arena, and/or keep the string storage in the context for reuse. Patch by Agustín Bergé. llvm-svn: 218461
2014-09-26 03:43:56 +08:00
BackRefVec::iterator Found =
std::find(NameBackReferences.begin(), NameBackReferences.end(), Name);
MS ABI: Simplify microsoft mangling of template instantiations Use mangled template instantiation name as key for back references. Templates have their own context for back references, so their mangling is always the same regardless of context. This avoids mangling template instantiations twice. Patch by Agustín Bergé! llvm-svn: 210416
2014-06-08 12:51:13 +08:00
if (Found == NameBackReferences.end()) {
MS ABI: Avoid hashing back reference keys in mangler This patch replaces the back reference StringMap from the MS mangler with a SmallVector of strings. My previous patches reduced the number of hashes involved in back reference lookups, this one removes them completely. The back reference map contains at most 10 entries, which are likely to be of varying sizes and different initial subsequences, and which can easily became huge (due to templates and namespaces). The solution presented is the simplest possible one. Nevertheless, it's enough to reduce compilation times for a particular test case from 11.1s to 9s, versus 8.58s for the Itanium ABI. Possible further improvements include using a sorted vector (carefully to not introduce an extra comparison), storing the string contents in a common arena, and/or keep the string storage in the context for reuse. Patch by Agustín Bergé. llvm-svn: 218461
2014-09-26 03:43:56 +08:00
if (NameBackReferences.size() < 10)
NameBackReferences.push_back(Name);
[-cxx-abi microsoft] Create backrefs for <unnamed-type-`id'> 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
2013-11-26 01:50:19 +08:00
Out << Name << '@';
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
} else {
MS ABI: Avoid hashing back reference keys in mangler This patch replaces the back reference StringMap from the MS mangler with a SmallVector of strings. My previous patches reduced the number of hashes involved in back reference lookups, this one removes them completely. The back reference map contains at most 10 entries, which are likely to be of varying sizes and different initial subsequences, and which can easily became huge (due to templates and namespaces). The solution presented is the simplest possible one. Nevertheless, it's enough to reduce compilation times for a particular test case from 11.1s to 9s, versus 8.58s for the Itanium ABI. Possible further improvements include using a sorted vector (carefully to not introduce an extra comparison), storing the string contents in a common arena, and/or keep the string storage in the context for reuse. Patch by Agustín Bergé. llvm-svn: 218461
2014-09-26 03:43:56 +08:00
Out << (Found - NameBackReferences.begin());
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
}
void MicrosoftCXXNameMangler::mangleObjCMethodName(const ObjCMethodDecl *MD) {
Context.mangleObjCMethodName(MD, Out);
}
void MicrosoftCXXNameMangler::mangleTemplateInstantiationName(
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
const TemplateDecl *TD, const TemplateArgumentList &TemplateArgs) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// <template-name> ::= <unscoped-template-name> <template-args>
// ::= <substitution>
// Always start with the unqualified name.
// Templates have their own context for back references.
ArgBackRefMap OuterArgsContext;
MS ABI: Avoid hashing back reference keys in mangler This patch replaces the back reference StringMap from the MS mangler with a SmallVector of strings. My previous patches reduced the number of hashes involved in back reference lookups, this one removes them completely. The back reference map contains at most 10 entries, which are likely to be of varying sizes and different initial subsequences, and which can easily became huge (due to templates and namespaces). The solution presented is the simplest possible one. Nevertheless, it's enough to reduce compilation times for a particular test case from 11.1s to 9s, versus 8.58s for the Itanium ABI. Possible further improvements include using a sorted vector (carefully to not introduce an extra comparison), storing the string contents in a common arena, and/or keep the string storage in the context for reuse. Patch by Agustín Bergé. llvm-svn: 218461
2014-09-26 03:43:56 +08:00
BackRefVec OuterTemplateContext;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
NameBackReferences.swap(OuterTemplateContext);
TypeBackReferences.swap(OuterArgsContext);
mangleUnscopedTemplateName(TD);
[ms-cxxabi] Fix assertion on unhandled function template arg types This code was changed in r158376 to get template argument source info for better diagnostics, but the current code asserts for any kind of unsupported template argument before it can issue a diagnostic. This change goes back to the Itanium implementation of isTemplate() and puts the argument index into the diagnostic instead of a source location. Review URL: http://llvm-reviews.chandlerc.com/D553 llvm-svn: 177471
2013-03-20 09:40:23 +08:00
mangleTemplateArgs(TD, TemplateArgs);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// Restore the previous back reference contexts.
NameBackReferences.swap(OuterTemplateContext);
TypeBackReferences.swap(OuterArgsContext);
}
void
MicrosoftCXXNameMangler::mangleUnscopedTemplateName(const TemplateDecl *TD) {
// <unscoped-template-name> ::= ?$ <unqualified-name>
Out << "?$";
mangleUnqualifiedName(TD);
}
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
void MicrosoftCXXNameMangler::mangleIntegerLiteral(const llvm::APSInt &Value,
bool IsBoolean) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// <integer-literal> ::= $0 <number>
Out << "$0";
// Make sure booleans are encoded as 0/1.
if (IsBoolean && Value.getBoolValue())
mangleNumber(1);
MS ABI: Fix mangling of unsigned int template params llvm-svn: 223999
2014-12-11 13:47:10 +08:00
else if (Value.isSigned())
[-cxx-abi microsoft] Mangle large integral constants correctly 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
2013-12-09 18:44:32 +08:00
mangleNumber(Value.getSExtValue());
MS ABI: Fix mangling of unsigned int template params llvm-svn: 223999
2014-12-11 13:47:10 +08:00
else
mangleNumber(Value.getZExtValue());
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
void MicrosoftCXXNameMangler::mangleExpression(const Expr *E) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// See if this is a constant expression.
llvm::APSInt Value;
if (E->isIntegerConstantExpr(Value, Context.getASTContext())) {
mangleIntegerLiteral(Value, E->getType()->isBooleanType());
return;
}
Fix mangling of __uuidof after two levels of template instantiation llvm-svn: 210570
2014-06-11 04:06:25 +08:00
// Look through no-op casts like template parameter substitutions.
E = E->IgnoreParenNoopCasts(Context.getASTContext());
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
const CXXUuidofExpr *UE = nullptr;
[-cxx-abi microsoft] Mangle __uuidof correctly into template parameters Summary: It seems that __uuidof introduces a global extern "C" declaration of type __s_GUID. However, our implementation of __uuidof does not provide such a declaration and thus must open-code the mangling for __uuidof in template parameters. This allows us to codegen scoped COM pointers and other such things. This fixes PR16836. Depends on D1356. Reviewers: rnk, cdavis5x, rsmith Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1357 llvm-svn: 188252
2013-08-13 14:32:20 +08:00
if (const UnaryOperator *UO = dyn_cast<UnaryOperator>(E)) {
if (UO->getOpcode() == UO_AddrOf)
UE = dyn_cast<CXXUuidofExpr>(UO->getSubExpr());
} else
UE = dyn_cast<CXXUuidofExpr>(E);
if (UE) {
// This CXXUuidofExpr is mangled as-if it were actually a VarDecl from
// const __s_GUID _GUID_{lower case UUID with underscores}
StringRef Uuid = UE->getUuidAsStringRef(Context.getASTContext());
std::string Name = "_GUID_" + Uuid.lower();
std::replace(Name.begin(), Name.end(), '-', '_');
Fix typo in comment. Thanks Kim Gräsman! llvm-svn: 188257
2013-08-13 17:17:25 +08:00
// If we had to peek through an address-of operator, treat this like we are
[-cxx-abi microsoft] Mangle __uuidof correctly into template parameters Summary: It seems that __uuidof introduces a global extern "C" declaration of type __s_GUID. However, our implementation of __uuidof does not provide such a declaration and thus must open-code the mangling for __uuidof in template parameters. This allows us to codegen scoped COM pointers and other such things. This fixes PR16836. Depends on D1356. Reviewers: rnk, cdavis5x, rsmith Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1357 llvm-svn: 188252
2013-08-13 14:32:20 +08:00
// dealing with a pointer type. Otherwise, treat it like a const reference.
//
// N.B. This matches up with the handling of TemplateArgument::Declaration
// in mangleTemplateArg
if (UE == E)
Out << "$E?";
else
Out << "$1?";
Out << Name << "@@3U__s_GUID@@B";
return;
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// As bad as this diagnostic is, it's better than crashing.
DiagnosticsEngine &Diags = Context.getDiags();
MS ABI: Cleanup some egregious style violations No functional change. llvm-svn: 206944
2014-04-23 13:16:51 +08:00
unsigned DiagID = Diags.getCustomDiagID(
DiagnosticsEngine::Error, "cannot yet mangle expression type %0");
Diags.Report(E->getExprLoc(), DiagID) << E->getStmtClassName()
<< E->getSourceRange();
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
MS ABI: Simplify mangleTemplateArgs No functionality change. llvm-svn: 205154
2014-03-31 00:30:54 +08:00
void MicrosoftCXXNameMangler::mangleTemplateArgs(
const TemplateDecl *TD, const TemplateArgumentList &TemplateArgs) {
Avoid extra back reference key lookup in msmangler Avoid a second key lookup when the back reference key is going to be inserted in the StringMap. The string lookups in the msmangler are the main responsible for the huge overhead when compared to the itanium mangler. This patch makes a small but noticeable improvement. Reviewed by: rnk Differential Revision: http://reviews.llvm.org/D4130 Patch by Agustín Bergé! llvm-svn: 211813
2014-06-27 06:42:18 +08:00
// <template-args> ::= <template-arg>+
MS ABI: Mangle empty type parameter packs compatibly The MS mangling scheme apparently has separate manglings for type and non-type parameter packs when they are empty. Match template arguments with parameters during mangling; check the parameter to see if it was destined to hold type-ish things or nontype-ish things. Differential Revision: http://reviews.llvm.org/D4792 llvm-svn: 214932
2014-08-06 06:43:45 +08:00
const TemplateParameterList *TPL = TD->getTemplateParameters();
assert(TPL->size() == TemplateArgs.size() &&
"size mismatch between args and parms!");
unsigned Idx = 0;
MS ABI: Simplify mangleTemplateArgs No functionality change. llvm-svn: 205154
2014-03-31 00:30:54 +08:00
for (const TemplateArgument &TA : TemplateArgs.asArray())
MS ABI: Mangle empty type parameter packs compatibly The MS mangling scheme apparently has separate manglings for type and non-type parameter packs when they are empty. Match template arguments with parameters during mangling; check the parameter to see if it was destined to hold type-ish things or nontype-ish things. Differential Revision: http://reviews.llvm.org/D4792 llvm-svn: 214932
2014-08-06 06:43:45 +08:00
mangleTemplateArg(TD, TA, TPL->getParam(Idx++));
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[ms-cxxabi] Mangle variadic template parameter packs Unlike Itanium, there is no code to indicate the beginning of a parameter pack. I tested this with MSVC 2013, which is the only version that implements variadic templates so far. This is needed to compile APInt.cpp for the MS C++ ABI. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D1077 llvm-svn: 185454
2013-07-03 02:10:07 +08:00
void MicrosoftCXXNameMangler::mangleTemplateArg(const TemplateDecl *TD,
MS ABI: Mangle empty type parameter packs compatibly The MS mangling scheme apparently has separate manglings for type and non-type parameter packs when they are empty. Match template arguments with parameters during mangling; check the parameter to see if it was destined to hold type-ish things or nontype-ish things. Differential Revision: http://reviews.llvm.org/D4792 llvm-svn: 214932
2014-08-06 06:43:45 +08:00
const TemplateArgument &TA,
const NamedDecl *Parm) {
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
// <template-arg> ::= <type>
// ::= <integer-literal>
// ::= <member-data-pointer>
// ::= <member-function-pointer>
// ::= $E? <name> <type-encoding>
// ::= $1? <name> <type-encoding>
// ::= $0A@
// ::= <template-args>
[ms-cxxabi] Mangle variadic template parameter packs Unlike Itanium, there is no code to indicate the beginning of a parameter pack. I tested this with MSVC 2013, which is the only version that implements variadic templates so far. This is needed to compile APInt.cpp for the MS C++ ABI. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D1077 llvm-svn: 185454
2013-07-03 02:10:07 +08:00
switch (TA.getKind()) {
case TemplateArgument::Null:
llvm_unreachable("Can't mangle null template arguments!");
[-cxx-abi microsoft] Remove ArgIndex, we handle all template argument kinds! TemplateExpansion cannot happen here because MSVC doesn't mangle anything but the fully substituted template arguments. llvm-svn: 189325
2013-08-27 16:21:25 +08:00
case TemplateArgument::TemplateExpansion:
llvm_unreachable("Can't mangle template expansion arguments!");
[ms-cxxabi] Mangle variadic template parameter packs Unlike Itanium, there is no code to indicate the beginning of a parameter pack. I tested this with MSVC 2013, which is the only version that implements variadic templates so far. This is needed to compile APInt.cpp for the MS C++ ABI. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D1077 llvm-svn: 185454
2013-07-03 02:10:07 +08:00
case TemplateArgument::Type: {
QualType T = TA.getAsType();
mangleType(T, SourceRange(), QMM_Escape);
break;
}
[-cxx-abi microsoft] Mangle TemplateArgument::Declaration for references Summary: Properly mangle declarations showing up in template arguments that are reference parameters. Fun-fact: undname cannot handle these! Reviewers: rnk, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1356 llvm-svn: 188245
2013-08-13 09:25:35 +08:00
case TemplateArgument::Declaration: {
const NamedDecl *ND = cast<NamedDecl>(TA.getAsDecl());
MS ABI: Handle indirect field decls in template args Properly support fields that come from anonymous unions and structs when used as template arguments for pointer to data member params. llvm-svn: 200921
2014-02-06 20:46:52 +08:00
if (isa<FieldDecl>(ND) || isa<IndirectFieldDecl>(ND)) {
MS ABI: Use the most recent decl to check the inheritance model This was crashing compilation of DeclContext::buildLookupImpl<>. llvm-svn: 201013
2014-02-08 09:15:37 +08:00
mangleMemberDataPointer(
cast<CXXRecordDecl>(ND->getDeclContext())->getMostRecentDecl(),
cast<ValueDecl>(ND));
MS ABI: Fix mangling of static methods and function references 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
2014-02-06 02:59:38 +08:00
} else if (const FunctionDecl *FD = dyn_cast<FunctionDecl>(ND)) {
Fix -Wunused-variable 'FD' by using it instead of ND when they're equal but FD has a more precise type. llvm-svn: 200889
2014-02-06 07:53:29 +08:00
const CXXMethodDecl *MD = dyn_cast<CXXMethodDecl>(FD);
[MS ABI] Function encodings are always encoded in template arguments llvm-svn: 237547
2015-05-18 08:05:25 +08:00
if (MD && MD->isInstance()) {
MS ABI: Use the most recent decl to check the inheritance model This was crashing compilation of DeclContext::buildLookupImpl<>. llvm-svn: 201013
2014-02-08 09:15:37 +08:00
mangleMemberFunctionPointer(MD->getParent()->getMostRecentDecl(), MD);
[MS ABI] Function encodings are always encoded in template arguments llvm-svn: 237547
2015-05-18 08:05:25 +08:00
} else {
Out << "$1?";
mangleName(FD);
mangleFunctionEncoding(FD, /*ShouldMangle=*/true);
}
MS ABI: Fix mangling of static methods and function references 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
2014-02-06 02:59:38 +08:00
} else {
Rename TemplateArgument::getTypeForDecl to getParamTypeForDecl for clarity Code review feedback from Richard Smith on r219900. llvm-svn: 220060
2014-10-18 02:00:12 +08:00
mangle(ND, TA.getParamTypeForDecl()->isReferenceType() ? "$E?" : "$1?");
MS ABI: Fix mangling of static methods and function references 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
2014-02-06 02:59:38 +08:00
}
[ms-cxxabi] Mangle variadic template parameter packs Unlike Itanium, there is no code to indicate the beginning of a parameter pack. I tested this with MSVC 2013, which is the only version that implements variadic templates so far. This is needed to compile APInt.cpp for the MS C++ ABI. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D1077 llvm-svn: 185454
2013-07-03 02:10:07 +08:00
break;
[-cxx-abi microsoft] Mangle TemplateArgument::Declaration for references Summary: Properly mangle declarations showing up in template arguments that are reference parameters. Fun-fact: undname cannot handle these! Reviewers: rnk, cdavis5x Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1356 llvm-svn: 188245
2013-08-13 09:25:35 +08:00
}
[ms-cxxabi] Mangle variadic template parameter packs Unlike Itanium, there is no code to indicate the beginning of a parameter pack. I tested this with MSVC 2013, which is the only version that implements variadic templates so far. This is needed to compile APInt.cpp for the MS C++ ABI. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D1077 llvm-svn: 185454
2013-07-03 02:10:07 +08:00
case TemplateArgument::Integral:
mangleIntegerLiteral(TA.getAsIntegral(),
TA.getIntegralType()->isBooleanType());
break;
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
case TemplateArgument::NullPtr: {
QualType T = TA.getNullPtrType();
if (const MemberPointerType *MPT = T->getAs<MemberPointerType>()) {
MS ABI: Tweak pointer-to-member mangling/inheritance model selection 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
2014-02-06 18:59:19 +08:00
const CXXRecordDecl *RD = MPT->getMostRecentCXXRecordDecl();
MS ABI: Only class templates get complex nullptr pointer-to-member-functions r210637 regressed CodeGenCXX/mangle-ms-templates-memptrs.cpp because it did not believe that there is a distinction between class templates and function templates. Sadly, there is. Function templates should behave in a compatible manner with MSVC. llvm-svn: 210642
2014-06-11 15:08:37 +08:00
if (MPT->isMemberFunctionPointerType() && isa<ClassTemplateDecl>(TD)) {
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
mangleMemberFunctionPointer(RD, nullptr);
MS ABI: Only class templates get complex nullptr pointer-to-member-functions r210637 regressed CodeGenCXX/mangle-ms-templates-memptrs.cpp because it did not believe that there is a distinction between class templates and function templates. Sadly, there is. Function templates should behave in a compatible manner with MSVC. llvm-svn: 210642
2014-06-11 15:08:37 +08:00
return;
}
if (MPT->isMemberDataPointer()) {
[MS ABI] nullptr data member ptrs are mangled differently for classes vs fns It turns out that nullptr pointers to data members act differently in function templates vs class templates. Class templates use a variable width representation proportional to the number of fields needed to materialize it. Function templates always use a single '0' template parameter. However, using '0' all the time is problematic if the class uses single or multiple inheritance. In those cases, use -1. llvm-svn: 241251
2015-07-02 17:43:11 +08:00
if (isa<ClassTemplateDecl>(TD)) {
mangleMemberDataPointer(RD, nullptr);
return;
}
// nullptr data pointers are always represented with a single field
// which is initialized with either 0 or -1. Why -1? Well, we need to
// distinguish the case where the data member is at offset zero in the
// record.
// However, we are free to use 0 *if* we would use multiple fields for
// non-nullptr member pointers.
if (!RD->nullFieldOffsetIsZero()) {
mangleIntegerLiteral(llvm::APSInt::get(-1), /*IsBoolean=*/false);
return;
}
MS ABI: Only class templates get complex nullptr pointer-to-member-functions r210637 regressed CodeGenCXX/mangle-ms-templates-memptrs.cpp because it did not believe that there is a distinction between class templates and function templates. Sadly, there is. Function templates should behave in a compatible manner with MSVC. llvm-svn: 210642
2014-06-11 15:08:37 +08:00
}
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
}
[MS ABI] nullptr data member ptrs are mangled differently for classes vs fns It turns out that nullptr pointers to data members act differently in function templates vs class templates. Class templates use a variable width representation proportional to the number of fields needed to materialize it. Function templates always use a single '0' template parameter. However, using '0' all the time is problematic if the class uses single or multiple inheritance. In those cases, use -1. llvm-svn: 241251
2015-07-02 17:43:11 +08:00
mangleIntegerLiteral(llvm::APSInt::getUnsigned(0), /*IsBoolean=*/false);
[ms-cxxabi] Mangle nullptr template arguments MSVC mangles nullptr template arguments identically to zero literals. llvm-svn: 187741
2013-08-06 05:33:59 +08:00
break;
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
}
[ms-cxxabi] Mangle variadic template parameter packs Unlike Itanium, there is no code to indicate the beginning of a parameter pack. I tested this with MSVC 2013, which is the only version that implements variadic templates so far. This is needed to compile APInt.cpp for the MS C++ ABI. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D1077 llvm-svn: 185454
2013-07-03 02:10:07 +08:00
case TemplateArgument::Expression:
mangleExpression(TA.getAsExpr());
break;
MS-ABI: Mangle empty template parameter packs correctly Tested for compatibility with VS2013. llvm-svn: 210198
2014-06-05 00:46:32 +08:00
case TemplateArgument::Pack: {
Remove llvm:: from uses of ArrayRef. llvm-svn: 211987
2014-06-29 07:22:23 +08:00
ArrayRef<TemplateArgument> TemplateArgs = TA.getPackAsArray();
MS-ABI: Mangle empty template parameter packs correctly Tested for compatibility with VS2013. llvm-svn: 210198
2014-06-05 00:46:32 +08:00
if (TemplateArgs.empty()) {
MS ABI: Mangle empty type parameter packs compatibly The MS mangling scheme apparently has separate manglings for type and non-type parameter packs when they are empty. Match template arguments with parameters during mangling; check the parameter to see if it was destined to hold type-ish things or nontype-ish things. Differential Revision: http://reviews.llvm.org/D4792 llvm-svn: 214932
2014-08-06 06:43:45 +08:00
if (isa<TemplateTypeParmDecl>(Parm) ||
isa<TemplateTemplateParmDecl>(Parm))
MS ABI: Empty pack expansions had their mangling changed in 2013->2015 We used to support the 2013 mangling and changed it to the more reasonable 2015 mangling. Let's make the mangling conditional on what version of MSVC is targeted. This fixes PR21888. llvm-svn: 232609
2015-03-18 11:56:27 +08:00
// MSVC 2015 changed the mangling for empty expanded template packs,
// use the old mangling for link compatibility for old versions.
Give isCompatibleWithMSVC a better interface We now use an enum which maps the marketing name (almost always a year) to the major version number. llvm-svn: 236967
2015-05-11 11:57:49 +08:00
Out << (Context.getASTContext().getLangOpts().isCompatibleWithMSVC(
LangOptions::MSVC2015)
MS ABI: Empty pack expansions had their mangling changed in 2013->2015 We used to support the 2013 mangling and changed it to the more reasonable 2015 mangling. Let's make the mangling conditional on what version of MSVC is targeted. This fixes PR21888. llvm-svn: 232609
2015-03-18 11:56:27 +08:00
? "$$V"
: "$$$V");
MS ABI: Mangle empty type parameter packs compatibly The MS mangling scheme apparently has separate manglings for type and non-type parameter packs when they are empty. Match template arguments with parameters during mangling; check the parameter to see if it was destined to hold type-ish things or nontype-ish things. Differential Revision: http://reviews.llvm.org/D4792 llvm-svn: 214932
2014-08-06 06:43:45 +08:00
else if (isa<NonTypeTemplateParmDecl>(Parm))
Out << "$S";
else
llvm_unreachable("unexpected template parameter decl!");
MS-ABI: Mangle empty template parameter packs correctly Tested for compatibility with VS2013. llvm-svn: 210198
2014-06-05 00:46:32 +08:00
} else {
for (const TemplateArgument &PA : TemplateArgs)
MS ABI: Mangle empty type parameter packs compatibly The MS mangling scheme apparently has separate manglings for type and non-type parameter packs when they are empty. Match template arguments with parameters during mangling; check the parameter to see if it was destined to hold type-ish things or nontype-ish things. Differential Revision: http://reviews.llvm.org/D4792 llvm-svn: 214932
2014-08-06 06:43:45 +08:00
mangleTemplateArg(TD, PA, Parm);
MS-ABI: Mangle empty template parameter packs correctly Tested for compatibility with VS2013. llvm-svn: 210198
2014-06-05 00:46:32 +08:00
}
[ms-cxxabi] Mangle variadic template parameter packs Unlike Itanium, there is no code to indicate the beginning of a parameter pack. I tested this with MSVC 2013, which is the only version that implements variadic templates so far. This is needed to compile APInt.cpp for the MS C++ ABI. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D1077 llvm-svn: 185454
2013-07-03 02:10:07 +08:00
break;
MS-ABI: Mangle empty template parameter packs correctly Tested for compatibility with VS2013. llvm-svn: 210198
2014-06-05 00:46:32 +08:00
}
MS ABI: Mangle alias templates used as template-template arguments A templated using declaration may be used as a template-template argument. Unfortunately, the VS "14" chooses '?' as the sole marker for the argument. This is problematic because it presupposes the possibility of using more than one template-aliases as arguments to the same template. This fixes PR20047. llvm-svn: 214290
2014-07-30 16:20:03 +08:00
case TemplateArgument::Template: {
const NamedDecl *ND =
TA.getAsTemplate().getAsTemplateDecl()->getTemplatedDecl();
if (const auto *TD = dyn_cast<TagDecl>(ND)) {
mangleType(TD);
} else if (isa<TypeAliasDecl>(ND)) {
MS ABI: Update alias template mangling for VC "14" CTP 3 MSVC "14" CTP 3 has fixed it's mangling for alias templates when used as template-template arguments; update clang to be compatible with this mangling. llvm-svn: 215972
2014-08-19 15:29:03 +08:00
Out << "$$Y";
mangleName(ND);
MS ABI: Mangle alias templates used as template-template arguments A templated using declaration may be used as a template-template argument. Unfortunately, the VS "14" chooses '?' as the sole marker for the argument. This is problematic because it presupposes the possibility of using more than one template-aliases as arguments to the same template. This fixes PR20047. llvm-svn: 214290
2014-07-30 16:20:03 +08:00
} else {
llvm_unreachable("unexpected template template NamedDecl!");
}
[ms-cxxabi] Handle template-template arguments Template-template arguments appear to be a rather simple encoding of the template's templated tag type. llvm-svn: 187751
2013-08-06 06:26:46 +08:00
break;
[ms-cxxabi] Mangle variadic template parameter packs Unlike Itanium, there is no code to indicate the beginning of a parameter pack. I tested this with MSVC 2013, which is the only version that implements variadic templates so far. This is needed to compile APInt.cpp for the MS C++ ABI. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D1077 llvm-svn: 185454
2013-07-03 02:10:07 +08:00
}
MS ABI: Mangle alias templates used as template-template arguments A templated using declaration may be used as a template-template argument. Unfortunately, the VS "14" chooses '?' as the sole marker for the argument. This is problematic because it presupposes the possibility of using more than one template-aliases as arguments to the same template. This fixes PR20047. llvm-svn: 214290
2014-07-30 16:20:03 +08:00
}
[ms-cxxabi] Mangle variadic template parameter packs Unlike Itanium, there is no code to indicate the beginning of a parameter pack. I tested this with MSVC 2013, which is the only version that implements variadic templates so far. This is needed to compile APInt.cpp for the MS C++ ABI. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D1077 llvm-svn: 185454
2013-07-03 02:10:07 +08:00
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void MicrosoftCXXNameMangler::mangleQualifiers(Qualifiers Quals,
bool IsMember) {
// <cvr-qualifiers> ::= [E] [F] [I] <base-cvr-qualifiers>
// 'E' means __ptr64 (32-bit only); 'F' means __unaligned (32/64-bit only);
// 'I' means __restrict (32/64-bit).
// Note that the MSVC __restrict keyword isn't the same as the C99 restrict
// keyword!
// <base-cvr-qualifiers> ::= A # near
// ::= B # near const
// ::= C # near volatile
// ::= D # near const volatile
// ::= E # far (16-bit)
// ::= F # far const (16-bit)
// ::= G # far volatile (16-bit)
// ::= H # far const volatile (16-bit)
// ::= I # huge (16-bit)
// ::= J # huge const (16-bit)
// ::= K # huge volatile (16-bit)
// ::= L # huge const volatile (16-bit)
// ::= M <basis> # based
// ::= N <basis> # based const
// ::= O <basis> # based volatile
// ::= P <basis> # based const volatile
// ::= Q # near member
// ::= R # near const member
// ::= S # near volatile member
// ::= T # near const volatile member
// ::= U # far member (16-bit)
// ::= V # far const member (16-bit)
// ::= W # far volatile member (16-bit)
// ::= X # far const volatile member (16-bit)
// ::= Y # huge member (16-bit)
// ::= Z # huge const member (16-bit)
// ::= 0 # huge volatile member (16-bit)
// ::= 1 # huge const volatile member (16-bit)
// ::= 2 <basis> # based member
// ::= 3 <basis> # based const member
// ::= 4 <basis> # based volatile member
// ::= 5 <basis> # based const volatile member
// ::= 6 # near function (pointers only)
// ::= 7 # far function (pointers only)
// ::= 8 # near method (pointers only)
// ::= 9 # far method (pointers only)
// ::= _A <basis> # based function (pointers only)
// ::= _B <basis> # based function (far?) (pointers only)
// ::= _C <basis> # based method (pointers only)
// ::= _D <basis> # based method (far?) (pointers only)
// ::= _E # block (Clang)
// <basis> ::= 0 # __based(void)
// ::= 1 # __based(segment)?
// ::= 2 <name> # __based(name)
// ::= 3 # ?
// ::= 4 # ?
// ::= 5 # not really based
bool HasConst = Quals.hasConst(),
HasVolatile = Quals.hasVolatile();
[ms-cxxabi] Properly mangle member pointers There were three things missing from the original implementation: - We would omit the 'E' qualifier for members int 64-bit mode. - We would not exmaine the qualifiers in 'IsMember' mode. - We didn't generate the correct backref to the base class. llvm-svn: 187753
2013-08-06 06:43:06 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
if (!IsMember) {
if (HasConst && HasVolatile) {
Out << 'D';
} else if (HasVolatile) {
Out << 'C';
} else if (HasConst) {
Out << 'B';
} else {
Out << 'A';
}
} else {
if (HasConst && HasVolatile) {
Out << 'T';
} else if (HasVolatile) {
Out << 'S';
} else if (HasConst) {
Out << 'R';
} else {
Out << 'Q';
}
}
// FIXME: For now, just drop all extension qualifiers on the floor.
}
MS ABI: Implement mangling for ref-qualifiers on methods Mangle ref-qualifiers like the Nov 2013 CTP. This fixes PR19361. llvm-svn: 206946
2014-04-23 13:16:56 +08:00
void
MicrosoftCXXNameMangler::mangleRefQualifier(RefQualifierKind RefQualifier) {
// <ref-qualifier> ::= G # lvalue reference
// ::= H # rvalue-reference
switch (RefQualifier) {
case RQ_None:
break;
case RQ_LValue:
Out << 'G';
break;
case RQ_RValue:
Out << 'H';
break;
}
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::manglePointerExtQualifiers(Qualifiers Quals,
QualType PointeeType) {
MS ABI: Refactor extended qualifiers 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
2014-02-18 22:20:10 +08:00
bool HasRestrict = Quals.hasRestrict();
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
if (PointersAre64Bit &&
(PointeeType.isNull() || !PointeeType->isFunctionType()))
MS ABI: Refactor extended qualifiers 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
2014-02-18 22:20:10 +08:00
Out << 'E';
if (HasRestrict)
Out << 'I';
}
void MicrosoftCXXNameMangler::manglePointerCVQualifiers(Qualifiers Quals) {
// <pointer-cv-qualifiers> ::= P # no qualifiers
// ::= Q # const
// ::= R # volatile
// ::= S # const volatile
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
bool HasConst = Quals.hasConst(),
MS ABI: Refactor extended qualifiers 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
2014-02-18 22:20:10 +08:00
HasVolatile = Quals.hasVolatile();
MS ABI: Add support for mangling __restrict 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
2014-02-18 20:58:35 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
if (HasConst && HasVolatile) {
Out << 'S';
} else if (HasVolatile) {
Out << 'R';
} else if (HasConst) {
Out << 'Q';
} else {
Out << 'P';
}
}
void MicrosoftCXXNameMangler::mangleArgumentType(QualType T,
SourceRange Range) {
[ms-cxxabi] Use sugared types in the mangler instead of canonical types At this point, it's clear that the MSVC mangler uses the type-as-written instead of the canonical type, so this should bring us closer to MSVC. The main thrust of this change is to fix the way we mangle decayed array parameters of function pointer parameters. With a DecayedType sugar node, this code can now be much simpler. Fixes PR16096. This also fixes a separate issue that Richard spotted in review. Because separate declarations of the same entity can be spelled and mangled differently, MSVC always mangles the earliest declaration in an attempt to avoid link errors. Clang now does the same. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D844 llvm-svn: 184777
2013-06-25 03:21:52 +08:00
// MSVC will backreference two canonically equivalent types that have slightly
// different manglings when mangled alone.
[-cxx-abi microsoft] Canonicalize array parameters better 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
2013-09-11 12:44:30 +08:00
// Decayed types do not match up with non-decayed versions of the same type.
//
// e.g.
// void (*x)(void) will not form a backreference with void x(void)
void *TypePtr;
[MS ABI] Treat ConstantArrayType like IncompleteArrayType in args Type backreferences for arguments use the DecayedType's original type. Because of this, arguments with the same canonical type with the same mangling would not backreference each other if one was a ConstantArrayType while the other was an IncompleteArrayType. Solve this by canonicalizing the ConstantArrayType to a suitable IncompleteArrayType. This fixes PR23325. llvm-svn: 235572
2015-04-23 13:21:20 +08:00
if (const auto *DT = T->getAs<DecayedType>()) {
QualType OriginalType = DT->getOriginalType();
[MS ABI] Rephrase the mangling of array types in parameters Make the canonicalization of array types more consistent. llvm-svn: 235831
2015-04-27 11:07:47 +08:00
// All decayed ArrayTypes should be treated identically; as-if they were
// a decayed IncompleteArrayType.
if (const auto *AT = getASTContext().getAsArrayType(OriginalType))
[MS ABI] Treat ConstantArrayType like IncompleteArrayType in args Type backreferences for arguments use the DecayedType's original type. Because of this, arguments with the same canonical type with the same mangling would not backreference each other if one was a ConstantArrayType while the other was an IncompleteArrayType. Solve this by canonicalizing the ConstantArrayType to a suitable IncompleteArrayType. This fixes PR23325. llvm-svn: 235572
2015-04-23 13:21:20 +08:00
OriginalType = getASTContext().getIncompleteArrayType(
[MS ABI] Rephrase the mangling of array types in parameters Make the canonicalization of array types more consistent. llvm-svn: 235831
2015-04-27 11:07:47 +08:00
AT->getElementType(), AT->getSizeModifier(),
AT->getIndexTypeCVRQualifiers());
[MS ABI] Treat ConstantArrayType like IncompleteArrayType in args Type backreferences for arguments use the DecayedType's original type. Because of this, arguments with the same canonical type with the same mangling would not backreference each other if one was a ConstantArrayType while the other was an IncompleteArrayType. Solve this by canonicalizing the ConstantArrayType to a suitable IncompleteArrayType. This fixes PR23325. llvm-svn: 235572
2015-04-23 13:21:20 +08:00
TypePtr = OriginalType.getCanonicalType().getAsOpaquePtr();
[-cxx-abi microsoft] Canonicalize array parameters better 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
2013-09-11 12:44:30 +08:00
// If the original parameter was textually written as an array,
// instead treat the decayed parameter like it's const.
//
// e.g.
// int [] -> int * const
[MS ABI] Treat ConstantArrayType like IncompleteArrayType in args Type backreferences for arguments use the DecayedType's original type. Because of this, arguments with the same canonical type with the same mangling would not backreference each other if one was a ConstantArrayType while the other was an IncompleteArrayType. Solve this by canonicalizing the ConstantArrayType to a suitable IncompleteArrayType. This fixes PR23325. llvm-svn: 235572
2015-04-23 13:21:20 +08:00
if (OriginalType->isArrayType())
[-cxx-abi microsoft] Canonicalize array parameters better 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
2013-09-11 12:44:30 +08:00
T = T.withConst();
[MS ABI] Treat ConstantArrayType like IncompleteArrayType in args Type backreferences for arguments use the DecayedType's original type. Because of this, arguments with the same canonical type with the same mangling would not backreference each other if one was a ConstantArrayType while the other was an IncompleteArrayType. Solve this by canonicalizing the ConstantArrayType to a suitable IncompleteArrayType. This fixes PR23325. llvm-svn: 235572
2015-04-23 13:21:20 +08:00
} else {
[-cxx-abi microsoft] Canonicalize array parameters better 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
2013-09-11 12:44:30 +08:00
TypePtr = T.getCanonicalType().getAsOpaquePtr();
[MS ABI] Treat ConstantArrayType like IncompleteArrayType in args Type backreferences for arguments use the DecayedType's original type. Because of this, arguments with the same canonical type with the same mangling would not backreference each other if one was a ConstantArrayType while the other was an IncompleteArrayType. Solve this by canonicalizing the ConstantArrayType to a suitable IncompleteArrayType. This fixes PR23325. llvm-svn: 235572
2015-04-23 13:21:20 +08:00
}
[-cxx-abi microsoft] Canonicalize array parameters better 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
2013-09-11 12:44:30 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
ArgBackRefMap::iterator Found = TypeBackReferences.find(TypePtr);
if (Found == TypeBackReferences.end()) {
Replace GetNumBytesInBuffer() in MicrosoftCXXNameMangler::mangleArgumentType by tell(). Using GetNumBytesInBuffer() assumes that the stream was not flushed between the GetNumBytesInBuffer() calls, which may happen to be true or not, depending on stream policy. tell() always reports the correct stream location. Do note there are only two more uses of GetNumBytesInBuffer() in LLVM+clang, in lib/MC/MCAsmStreamer.cpp and lib/Target/R600/InstPrinter/AMDGPUInstPrinter.cpp. The former may be replacable by tell (needs testing) but while the later can not be immediatly replaced by tell() as it uses the absolute value of GetNumBytesInBuffer() rather than the real stream position. Both uses seems to depend upon flush policy and thus may not work correctly depending upon the stream behaviour. Going forward, GetNumBytesInBuffer() should probably be protected, non-accessible to raw_ostream clients. llvm-svn: 236389
2015-05-02 23:31:08 +08:00
size_t OutSizeBefore = Out.tell();
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
[-cxx-abi microsoft] Canonicalize array parameters better 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
2013-09-11 12:44:30 +08:00
mangleType(T, Range, QMM_Drop);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// See if it's worth creating a back reference.
// Only types longer than 1 character are considered
// and only 10 back references slots are available:
Replace GetNumBytesInBuffer() in MicrosoftCXXNameMangler::mangleArgumentType by tell(). Using GetNumBytesInBuffer() assumes that the stream was not flushed between the GetNumBytesInBuffer() calls, which may happen to be true or not, depending on stream policy. tell() always reports the correct stream location. Do note there are only two more uses of GetNumBytesInBuffer() in LLVM+clang, in lib/MC/MCAsmStreamer.cpp and lib/Target/R600/InstPrinter/AMDGPUInstPrinter.cpp. The former may be replacable by tell (needs testing) but while the later can not be immediatly replaced by tell() as it uses the absolute value of GetNumBytesInBuffer() rather than the real stream position. Both uses seems to depend upon flush policy and thus may not work correctly depending upon the stream behaviour. Going forward, GetNumBytesInBuffer() should probably be protected, non-accessible to raw_ostream clients. llvm-svn: 236389
2015-05-02 23:31:08 +08:00
bool LongerThanOneChar = (Out.tell() - OutSizeBefore > 1);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
if (LongerThanOneChar && TypeBackReferences.size() < 10) {
size_t Size = TypeBackReferences.size();
TypeBackReferences[TypePtr] = Size;
}
} else {
Out << Found->second;
}
}
void MicrosoftCXXNameMangler::mangleType(QualType T, SourceRange Range,
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
QualifierMangleMode QMM) {
[ms-cxxabi] Use sugared types in the mangler instead of canonical types At this point, it's clear that the MSVC mangler uses the type-as-written instead of the canonical type, so this should bring us closer to MSVC. The main thrust of this change is to fix the way we mangle decayed array parameters of function pointer parameters. With a DecayedType sugar node, this code can now be much simpler. Fixes PR16096. This also fixes a separate issue that Richard spotted in review. Because separate declarations of the same entity can be spelled and mangled differently, MSVC always mangles the earliest declaration in an attempt to avoid link errors. Clang now does the same. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D844 llvm-svn: 184777
2013-06-25 03:21:52 +08:00
// Don't use the canonical types. MSVC includes things like 'const' on
// pointer arguments to function pointers that canonicalization strips away.
T = T.getDesugaredType(getASTContext());
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
Qualifiers Quals = T.getLocalQualifiers();
[ms-cxxabi] Use sugared types in the mangler instead of canonical types At this point, it's clear that the MSVC mangler uses the type-as-written instead of the canonical type, so this should bring us closer to MSVC. The main thrust of this change is to fix the way we mangle decayed array parameters of function pointer parameters. With a DecayedType sugar node, this code can now be much simpler. Fixes PR16096. This also fixes a separate issue that Richard spotted in review. Because separate declarations of the same entity can be spelled and mangled differently, MSVC always mangles the earliest declaration in an attempt to avoid link errors. Clang now does the same. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D844 llvm-svn: 184777
2013-06-25 03:21:52 +08:00
if (const ArrayType *AT = getASTContext().getAsArrayType(T)) {
// If there were any Quals, getAsArrayType() pushed them onto the array
// element type.
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
if (QMM == QMM_Mangle)
Out << 'A';
else if (QMM == QMM_Escape || QMM == QMM_Result)
Out << "$$B";
[ms-cxxabi] Use sugared types in the mangler instead of canonical types At this point, it's clear that the MSVC mangler uses the type-as-written instead of the canonical type, so this should bring us closer to MSVC. The main thrust of this change is to fix the way we mangle decayed array parameters of function pointer parameters. With a DecayedType sugar node, this code can now be much simpler. Fixes PR16096. This also fixes a separate issue that Richard spotted in review. Because separate declarations of the same entity can be spelled and mangled differently, MSVC always mangles the earliest declaration in an attempt to avoid link errors. Clang now does the same. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D844 llvm-svn: 184777
2013-06-25 03:21:52 +08:00
mangleArrayType(AT);
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
return;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
bool IsPointer = T->isAnyPointerType() || T->isMemberPointerType() ||
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
T->isReferenceType() || T->isBlockPointerType();
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
switch (QMM) {
case QMM_Drop:
break;
case QMM_Mangle:
if (const FunctionType *FT = dyn_cast<FunctionType>(T)) {
Out << '6';
Simplify MicrosoftCXXNameMangler::mangleFunctionType llvm-svn: 191950
2013-10-04 19:25:05 +08:00
mangleFunctionType(FT);
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
return;
}
mangleQualifiers(Quals, false);
break;
case QMM_Escape:
if (!IsPointer && Quals) {
Out << "$$C";
mangleQualifiers(Quals, false);
}
break;
case QMM_Result:
if ((!IsPointer && Quals) || isa<TagType>(T)) {
Out << '?';
mangleQualifiers(Quals, false);
}
break;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
const Type *ty = T.getTypePtr();
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
switch (ty->getTypeClass()) {
#define ABSTRACT_TYPE(CLASS, PARENT)
#define NON_CANONICAL_TYPE(CLASS, PARENT) \
case Type::CLASS: \
llvm_unreachable("can't mangle non-canonical type " #CLASS "Type"); \
return;
#define TYPE(CLASS, PARENT) \
case Type::CLASS: \
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
mangleType(cast<CLASS##Type>(ty), Quals, Range); \
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
break;
#include "clang/AST/TypeNodes.def"
#undef ABSTRACT_TYPE
#undef NON_CANONICAL_TYPE
#undef TYPE
}
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const BuiltinType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range) {
// <type> ::= <builtin-type>
// <builtin-type> ::= X # void
// ::= C # signed char
// ::= D # char
// ::= E # unsigned char
// ::= F # short
// ::= G # unsigned short (or wchar_t if it's not a builtin)
// ::= H # int
// ::= I # unsigned int
// ::= J # long
// ::= K # unsigned long
// L # <none>
// ::= M # float
// ::= N # double
// ::= O # long double (__float80 is mangled differently)
// ::= _J # long long, __int64
// ::= _K # unsigned long long, __int64
// ::= _L # __int128
// ::= _M # unsigned __int128
// ::= _N # bool
// _O # <array in parameter>
// ::= _T # __float80 (Intel)
// ::= _W # wchar_t
// ::= _Z # __float80 (Digital Mars)
switch (T->getKind()) {
Run clang-format to unify the switch statement style as suggest here: http://reviews.llvm.org/D12855#246073. NFC. llvm-svn: 247678
2015-09-15 20:18:29 +08:00
case BuiltinType::Void:
Out << 'X';
break;
case BuiltinType::SChar:
Out << 'C';
break;
case BuiltinType::Char_U:
case BuiltinType::Char_S:
Out << 'D';
break;
case BuiltinType::UChar:
Out << 'E';
break;
case BuiltinType::Short:
Out << 'F';
break;
case BuiltinType::UShort:
Out << 'G';
break;
case BuiltinType::Int:
Out << 'H';
break;
case BuiltinType::UInt:
Out << 'I';
break;
case BuiltinType::Long:
Out << 'J';
break;
case BuiltinType::ULong:
Out << 'K';
break;
case BuiltinType::Float:
Out << 'M';
break;
case BuiltinType::Double:
Out << 'N';
break;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// TODO: Determine size and mangle accordingly
Run clang-format to unify the switch statement style as suggest here: http://reviews.llvm.org/D12855#246073. NFC. llvm-svn: 247678
2015-09-15 20:18:29 +08:00
case BuiltinType::LongDouble:
Out << 'O';
break;
case BuiltinType::LongLong:
Out << "_J";
break;
case BuiltinType::ULongLong:
Out << "_K";
break;
case BuiltinType::Int128:
Out << "_L";
break;
case BuiltinType::UInt128:
Out << "_M";
break;
case BuiltinType::Bool:
Out << "_N";
break;
case BuiltinType::Char16:
Out << "_S";
break;
case BuiltinType::Char32:
Out << "_U";
break;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case BuiltinType::WChar_S:
Run clang-format to unify the switch statement style as suggest here: http://reviews.llvm.org/D12855#246073. NFC. llvm-svn: 247678
2015-09-15 20:18:29 +08:00
case BuiltinType::WChar_U:
Out << "_W";
break;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
#define BUILTIN_TYPE(Id, SingletonId)
#define PLACEHOLDER_TYPE(Id, SingletonId) \
case BuiltinType::Id:
#include "clang/AST/BuiltinTypes.def"
case BuiltinType::Dependent:
llvm_unreachable("placeholder types shouldn't get to name mangling");
Run clang-format to unify the switch statement style as suggest here: http://reviews.llvm.org/D12855#246073. NFC. llvm-svn: 247678
2015-09-15 20:18:29 +08:00
case BuiltinType::ObjCId:
Out << "PAUobjc_object@@";
break;
case BuiltinType::ObjCClass:
Out << "PAUobjc_class@@";
break;
case BuiltinType::ObjCSel:
Out << "PAUobjc_selector@@";
break;
Re-commit r170428 changes with Linux style file endings. Add OpenCL images as clang builtin types. llvm-svn: 170432
2012-12-18 22:38:23 +08:00
Run clang-format to unify the switch statement style as suggest here: http://reviews.llvm.org/D12855#246073. NFC. llvm-svn: 247678
2015-09-15 20:18:29 +08:00
case BuiltinType::OCLImage1d:
Out << "PAUocl_image1d@@";
break;
case BuiltinType::OCLImage1dArray:
Out << "PAUocl_image1darray@@";
break;
case BuiltinType::OCLImage1dBuffer:
Out << "PAUocl_image1dbuffer@@";
break;
case BuiltinType::OCLImage2d:
Out << "PAUocl_image2d@@";
break;
case BuiltinType::OCLImage2dArray:
Out << "PAUocl_image2darray@@";
break;
[OpenCL] Add new types for OpenCL 2.0. Patch by Pedro Ferreira. Reviewers: pekka.jaaskelainen Differential Revision: http://reviews.llvm.org/D12855 llvm-svn: 247676
2015-09-15 19:18:52 +08:00
case BuiltinType::OCLImage2dDepth:
Out << "PAUocl_image2ddepth@@";
break;
case BuiltinType::OCLImage2dArrayDepth:
Out << "PAUocl_image2darraydepth@@";
break;
case BuiltinType::OCLImage2dMSAA:
Out << "PAUocl_image2dmsaa@@";
break;
case BuiltinType::OCLImage2dArrayMSAA:
Out << "PAUocl_image2darraymsaa@@";
break;
case BuiltinType::OCLImage2dMSAADepth:
Out << "PAUocl_image2dmsaadepth@@";
break;
case BuiltinType::OCLImage2dArrayMSAADepth:
Out << "PAUocl_image2darraymsaadepth@@";
break;
Run clang-format to unify the switch statement style as suggest here: http://reviews.llvm.org/D12855#246073. NFC. llvm-svn: 247678
2015-09-15 20:18:29 +08:00
case BuiltinType::OCLImage3d:
Out << "PAUocl_image3d@@";
break;
case BuiltinType::OCLSampler:
Out << "PAUocl_sampler@@";
break;
case BuiltinType::OCLEvent:
Out << "PAUocl_event@@";
break;
[OpenCL] Add new types for OpenCL 2.0. Patch by Pedro Ferreira. Reviewers: pekka.jaaskelainen Differential Revision: http://reviews.llvm.org/D12855 llvm-svn: 247676
2015-09-15 19:18:52 +08:00
case BuiltinType::OCLClkEvent:
Out << "PAUocl_clkevent@@";
break;
case BuiltinType::OCLQueue:
Out << "PAUocl_queue@@";
break;
case BuiltinType::OCLNDRange:
Out << "PAUocl_ndrange@@";
break;
case BuiltinType::OCLReserveID:
Out << "PAUocl_reserveid@@";
break;
[-cxx-abi microsoft] Remove trailing spaces from the mangler No functional change, just a tidying up. llvm-svn: 197196
2013-12-13 09:06:04 +08:00
Run clang-format to unify the switch statement style as suggest here: http://reviews.llvm.org/D12855#246073. NFC. llvm-svn: 247678
2015-09-15 20:18:29 +08:00
case BuiltinType::NullPtr:
Out << "$$T";
break;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case BuiltinType::Half: {
DiagnosticsEngine &Diags = Context.getDiags();
Run clang-format to unify the switch statement style as suggest here: http://reviews.llvm.org/D12855#246073. NFC. llvm-svn: 247678
2015-09-15 20:18:29 +08:00
unsigned DiagID = Diags.getCustomDiagID(
DiagnosticsEngine::Error, "cannot mangle this built-in %0 type yet");
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
Diags.Report(Range.getBegin(), DiagID)
Run clang-format to unify the switch statement style as suggest here: http://reviews.llvm.org/D12855#246073. NFC. llvm-svn: 247678
2015-09-15 20:18:29 +08:00
<< T->getName(Context.getASTContext().getPrintingPolicy()) << Range;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
break;
}
}
}
// <type> ::= <function-type>
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const FunctionProtoType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange) {
// Structors only appear in decls, so at this point we know it's not a
// structor type.
// FIXME: This may not be lambda-friendly.
MS ABI: Mangle this qualifiers on function types C++11 allows this qualifiers to exist on function types when used in template arguments. Previously, I believed it wasn't possible because MSVC rejected declarations like: S<int () const &> s; However, it turns out MSVC properly allows them in using declarations; updated clang to be compatible with this mangling. llvm-svn: 215464
2014-08-13 01:53:10 +08:00
if (T->getTypeQuals() || T->getRefQualifier() != RQ_None) {
Out << "$$A8@@";
mangleFunctionType(T, /*D=*/nullptr, /*ForceThisQuals=*/true);
} else {
Out << "$$A6";
mangleFunctionType(T);
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
void MicrosoftCXXNameMangler::mangleType(const FunctionNoProtoType *T,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers, SourceRange) {
AST: Implement mangling support for function types without a prototype. Function types without prototypes can arise when mangling a function type within an overloadable function in C. We mangle these as the absence of any parameter types (not even an empty parameter list). Differential Revision: http://reviews.llvm.org/D11848 llvm-svn: 244374
2015-08-08 07:25:47 +08:00
Out << "$$A6";
mangleFunctionType(T);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
void MicrosoftCXXNameMangler::mangleFunctionType(const FunctionType *T,
const FunctionDecl *D,
MS ABI: Mangle this qualifiers on function types C++11 allows this qualifiers to exist on function types when used in template arguments. Previously, I believed it wasn't possible because MSVC rejected declarations like: S<int () const &> s; However, it turns out MSVC properly allows them in using declarations; updated clang to be compatible with this mangling. llvm-svn: 215464
2014-08-13 01:53:10 +08:00
bool ForceThisQuals) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// <function-type> ::= <this-cvr-qualifiers> <calling-convention>
// <return-type> <argument-list> <throw-spec>
AST: Implement mangling support for function types without a prototype. Function types without prototypes can arise when mangling a function type within an overloadable function in C. We mangle these as the absence of any parameter types (not even an empty parameter list). Differential Revision: http://reviews.llvm.org/D11848 llvm-svn: 244374
2015-08-08 07:25:47 +08:00
const FunctionProtoType *Proto = dyn_cast<FunctionProtoType>(T);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
[ms-cxxabi] Use sugared types in the mangler instead of canonical types At this point, it's clear that the MSVC mangler uses the type-as-written instead of the canonical type, so this should bring us closer to MSVC. The main thrust of this change is to fix the way we mangle decayed array parameters of function pointer parameters. With a DecayedType sugar node, this code can now be much simpler. Fixes PR16096. This also fixes a separate issue that Richard spotted in review. Because separate declarations of the same entity can be spelled and mangled differently, MSVC always mangles the earliest declaration in an attempt to avoid link errors. Clang now does the same. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D844 llvm-svn: 184777
2013-06-25 03:21:52 +08:00
SourceRange Range;
if (D) Range = D->getSourceRange();
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
bool IsStructor = false, HasThisQuals = ForceThisQuals, IsCtorClosure = false;
CallingConv CC = T->getCallConv();
Simplify MicrosoftCXXNameMangler::mangleFunctionType llvm-svn: 191950
2013-10-04 19:25:05 +08:00
if (const CXXMethodDecl *MD = dyn_cast_or_null<CXXMethodDecl>(D)) {
if (MD->isInstance())
MS ABI: Mangle this qualifiers on function types C++11 allows this qualifiers to exist on function types when used in template arguments. Previously, I believed it wasn't possible because MSVC rejected declarations like: S<int () const &> s; However, it turns out MSVC properly allows them in using declarations; updated clang to be compatible with this mangling. llvm-svn: 215464
2014-08-13 01:53:10 +08:00
HasThisQuals = true;
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
if (isa<CXXDestructorDecl>(MD)) {
IsStructor = true;
} else if (isa<CXXConstructorDecl>(MD)) {
Simplify MicrosoftCXXNameMangler::mangleFunctionType llvm-svn: 191950
2013-10-04 19:25:05 +08:00
IsStructor = true;
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
IsCtorClosure = (StructorType == Ctor_CopyingClosure ||
StructorType == Ctor_DefaultClosure) &&
getStructor(MD) == Structor;
if (IsCtorClosure)
CC = getASTContext().getDefaultCallingConvention(
/*IsVariadic=*/false, /*IsCXXMethod=*/true);
}
Simplify MicrosoftCXXNameMangler::mangleFunctionType llvm-svn: 191950
2013-10-04 19:25:05 +08:00
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// If this is a C++ instance method, mangle the CVR qualifiers for the
// this pointer.
MS ABI: Mangle this qualifiers on function types C++11 allows this qualifiers to exist on function types when used in template arguments. Previously, I believed it wasn't possible because MSVC rejected declarations like: S<int () const &> s; However, it turns out MSVC properly allows them in using declarations; updated clang to be compatible with this mangling. llvm-svn: 215464
2014-08-13 01:53:10 +08:00
if (HasThisQuals) {
MS ABI: Refactor extended qualifiers 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
2014-02-18 22:20:10 +08:00
Qualifiers Quals = Qualifiers::fromCVRMask(Proto->getTypeQuals());
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
manglePointerExtQualifiers(Quals, /*PointeeType=*/QualType());
MS ABI: Implement mangling for ref-qualifiers on methods Mangle ref-qualifiers like the Nov 2013 CTP. This fixes PR19361. llvm-svn: 206946
2014-04-23 13:16:56 +08:00
mangleRefQualifier(Proto->getRefQualifier());
MS ABI: Mangle this qualifiers on function types C++11 allows this qualifiers to exist on function types when used in template arguments. Previously, I believed it wasn't possible because MSVC rejected declarations like: S<int () const &> s; However, it turns out MSVC properly allows them in using declarations; updated clang to be compatible with this mangling. llvm-svn: 215464
2014-08-13 01:53:10 +08:00
mangleQualifiers(Quals, /*IsMember=*/false);
[-cxx-abi microsoft] Mangle member pointers better Summary: There were several things going wrong: - We mangled in useless qualifiers like "volatile void" return types. - We didn't propagate 64-bit pointer markers sufficiently. - We mangled qualifiers belonging to the pointee incorrectly. This fixes PR16844 and PR16848. Reviewers: rnk, whunt Reviewed By: rnk CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1353 llvm-svn: 188450
2013-08-15 16:13:23 +08:00
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
mangleCallingConvention(CC);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// <return-type> ::= <type>
// ::= @ # structors (they have no declared return type)
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
if (IsStructor) {
if (isa<CXXDestructorDecl>(D) && D == Structor &&
StructorType == Dtor_Deleting) {
// The scalar deleting destructor takes an extra int argument.
// However, the FunctionType generated has 0 arguments.
// FIXME: This is a temporary hack.
// Maybe should fix the FunctionType creation instead?
Fix virtual destructor mangling when using "-cxx-abi microsoft" on x64 llvm-svn: 189214
2013-08-26 18:32:04 +08:00
Out << (PointersAre64Bit ? "PEAXI@Z" : "PAXI@Z");
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
return;
}
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
if (IsCtorClosure) {
// Default constructor closure and copy constructor closure both return
// void.
Out << 'X';
if (StructorType == Ctor_DefaultClosure) {
// Default constructor closure always has no arguments.
Out << 'X';
} else if (StructorType == Ctor_CopyingClosure) {
// Copy constructor closure always takes an unqualified reference.
mangleArgumentType(getASTContext().getLValueReferenceType(
Proto->getParamType(0)
->getAs<LValueReferenceType>()
->getPointeeType(),
/*SpelledAsLValue=*/true),
Range);
MS ABI: Generate default constructor closures The MS ABI utilizes a compiler generated function called the "vector constructor iterator" to construct arrays of objects with non-trivial constructors/destructors. For this to work, the constructor must follow a specific calling convention. A thunk must be created if the default constructor has default arguments, is variadic or is otherwise incompatible. This thunk is called the default constructor closure. N.B. Default constructor closures are only generated if the default constructor is exported because clang itself does not utilize vector constructor iterators. Failing to export the default constructor closure will result in link/load failure if a translation unit compiled with MSVC is on the import side. Differential Revision: http://reviews.llvm.org/D8331 llvm-svn: 232229
2015-03-14 06:36:55 +08:00
Out << '@';
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
} else {
llvm_unreachable("unexpected constructor closure!");
}
MS ABI: Generate default constructor closures The MS ABI utilizes a compiler generated function called the "vector constructor iterator" to construct arrays of objects with non-trivial constructors/destructors. For this to work, the constructor must follow a specific calling convention. A thunk must be created if the default constructor has default arguments, is variadic or is otherwise incompatible. This thunk is called the default constructor closure. N.B. Default constructor closures are only generated if the default constructor is exported because clang itself does not utilize vector constructor iterators. Failing to export the default constructor closure will result in link/load failure if a translation unit compiled with MSVC is on the import side. Differential Revision: http://reviews.llvm.org/D8331 llvm-svn: 232229
2015-03-14 06:36:55 +08:00
Out << 'Z';
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
return;
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
Out << '@';
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
} else {
AST: Implement mangling support for function types without a prototype. Function types without prototypes can arise when mangling a function type within an overloadable function in C. We mangle these as the absence of any parameter types (not even an empty parameter list). Differential Revision: http://reviews.llvm.org/D11848 llvm-svn: 244374
2015-08-08 07:25:47 +08:00
QualType ResultType = T->getReturnType();
MS ABI: Support mangling of return-types deducing to local types The MS ABI forces us into catch-22 when it comes to functions which return types which are local: - A function is mangled with it's return type. - A type is mangled with it's surrounding context. Avoid this by mangling auto and decltype(autp) directly into the function's return type. Using this mangling has the double advantage of being compatible with the C++ standard without crashing the compiler. N.B. For the curious, the MSVC mangling leads to collisions amongst template functions and either crashes when faced with local types or is otherwise incapable of returning them. llvm-svn: 205282
2014-04-01 13:29:46 +08:00
if (const auto *AT =
dyn_cast_or_null<AutoType>(ResultType->getContainedAutoType())) {
Out << '?';
mangleQualifiers(ResultType.getLocalQualifiers(), /*IsMember=*/false);
Out << '?';
mangleSourceName(AT->isDecltypeAuto() ? "<decltype-auto>" : "<auto>");
Out << '@';
} else {
if (ResultType->isVoidType())
ResultType = ResultType.getUnqualifiedType();
mangleType(ResultType, Range, QMM_Result);
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
// <argument-list> ::= X # void
// ::= <type>+ @
// ::= <type>* Z # varargs
AST: Implement mangling support for function types without a prototype. Function types without prototypes can arise when mangling a function type within an overloadable function in C. We mangle these as the absence of any parameter types (not even an empty parameter list). Differential Revision: http://reviews.llvm.org/D11848 llvm-svn: 244374
2015-08-08 07:25:47 +08:00
if (!Proto) {
// Function types without prototypes can arise when mangling a function type
// within an overloadable function in C. We mangle these as the absence of
// any parameter types (not even an empty parameter list).
Out << '@';
} else if (Proto->getNumParams() == 0 && !Proto->isVariadic()) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
Out << 'X';
} else {
[ms-cxxabi] Use sugared types in the mangler instead of canonical types At this point, it's clear that the MSVC mangler uses the type-as-written instead of the canonical type, so this should bring us closer to MSVC. The main thrust of this change is to fix the way we mangle decayed array parameters of function pointer parameters. With a DecayedType sugar node, this code can now be much simpler. Fixes PR16096. This also fixes a separate issue that Richard spotted in review. Because separate declarations of the same entity can be spelled and mangled differently, MSVC always mangles the earliest declaration in an attempt to avoid link errors. Clang now does the same. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D844 llvm-svn: 184777
2013-06-25 03:21:52 +08:00
// Happens for function pointer type arguments for example.
Change range-based for-loops to be -Wrange-loop-analysis clean. No functionality change. llvm-svn: 234964
2015-04-15 09:21:42 +08:00
for (const QualType &Arg : Proto->param_types())
[C++11] Replacing FunctionProtoType iterators param_type_begin() and param_type_end() with iterator_range param_types(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 204045
2014-03-17 23:23:01 +08:00
mangleArgumentType(Arg, Range);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// <builtin-type> ::= Z # ellipsis
if (Proto->isVariadic())
Out << 'Z';
else
Out << '@';
}
mangleThrowSpecification(Proto);
}
void MicrosoftCXXNameMangler::mangleFunctionClass(const FunctionDecl *FD) {
[ms-cxxabi] Mangle in an implicit 'E' for certain types on win64 Most of the complexity of this patch is figuring out which types get the qualifier and which don't. If we implement __ptr32/64, then we should check the qualifier instead of assuming all pointers are 64-bit. This fixes PR13792. Patch by Warren Hunt! llvm-svn: 181825
2013-05-15 04:30:42 +08:00
// <function-class> ::= <member-function> E? # E designates a 64-bit 'this'
// # pointer. in 64-bit mode *all*
// # 'this' pointers are 64-bit.
// ::= <global-function>
// <member-function> ::= A # private: near
// ::= B # private: far
// ::= C # private: static near
// ::= D # private: static far
// ::= E # private: virtual near
// ::= F # private: virtual far
// ::= I # protected: near
// ::= J # protected: far
// ::= K # protected: static near
// ::= L # protected: static far
// ::= M # protected: virtual near
// ::= N # protected: virtual far
// ::= Q # public: near
// ::= R # public: far
// ::= S # public: static near
// ::= T # public: static far
// ::= U # public: virtual near
// ::= V # public: virtual far
// <global-function> ::= Y # global near
// ::= Z # global far
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
if (const CXXMethodDecl *MD = dyn_cast<CXXMethodDecl>(FD)) {
switch (MD->getAccess()) {
Reland 192220 "Abstract out parts of thunk emission code, add support for simple thunks when using -cxx-abi microsoft" with relaxed assertions llvm-svn: 192285
2013-10-09 17:23:58 +08:00
case AS_none:
llvm_unreachable("Unsupported access specifier");
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case AS_private:
if (MD->isStatic())
Out << 'C';
else if (MD->isVirtual())
Out << 'E';
else
Out << 'A';
break;
case AS_protected:
if (MD->isStatic())
Out << 'K';
else if (MD->isVirtual())
Out << 'M';
else
Out << 'I';
break;
case AS_public:
if (MD->isStatic())
Out << 'S';
else if (MD->isVirtual())
Out << 'U';
else
Out << 'Q';
}
[MS ABI] Give __attribute__((overloadable)) functions pretty names It turns out that there is a mangling for 'extern "C"', it's only used by MSVC in /clr mode. Co-opt this mangling so that extern "C" functions marked overloadable get demangled nicely. llvm-svn: 237548
2015-05-18 08:05:29 +08:00
} else {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
Out << 'Y';
[MS ABI] Give __attribute__((overloadable)) functions pretty names It turns out that there is a mangling for 'extern "C"', it's only used by MSVC in /clr mode. Co-opt this mangling so that extern "C" functions marked overloadable get demangled nicely. llvm-svn: 237548
2015-05-18 08:05:29 +08:00
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
void MicrosoftCXXNameMangler::mangleCallingConvention(CallingConv CC) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// <calling-convention> ::= A # __cdecl
// ::= B # __export __cdecl
// ::= C # __pascal
// ::= D # __export __pascal
// ::= E # __thiscall
// ::= F # __export __thiscall
// ::= G # __stdcall
// ::= H # __export __stdcall
// ::= I # __fastcall
// ::= J # __export __fastcall
Add frontend support for __vectorcall Wire it through everywhere we have support for fastcall, essentially. This allows us to parse the MSVC "14" CTP headers, but we will miscompile them because LLVM doesn't support __vectorcall yet. Reviewed By: Aaron Ballman Differential Revision: http://reviews.llvm.org/D5808 llvm-svn: 220573
2014-10-25 01:42:17 +08:00
// ::= Q # __vectorcall
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// The 'export' calling conventions are from a bygone era
// (*cough*Win16*cough*) when functions were declared for export with
// that keyword. (It didn't actually export them, it just made them so
// that they could be in a DLL and somebody from another module could call
// them.)
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
switch (CC) {
default:
llvm_unreachable("Unsupported CC for mangling");
Add ms_abi and sysv_abi attribute handling. Based on a patch by Benno Rice! llvm-svn: 189644
2013-08-30 12:39:01 +08:00
case CC_X86_64Win64:
case CC_X86_64SysV:
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case CC_C: Out << 'A'; break;
case CC_X86Pascal: Out << 'C'; break;
case CC_X86ThisCall: Out << 'E'; break;
case CC_X86StdCall: Out << 'G'; break;
case CC_X86FastCall: Out << 'I'; break;
Add frontend support for __vectorcall Wire it through everywhere we have support for fastcall, essentially. This allows us to parse the MSVC "14" CTP headers, but we will miscompile them because LLVM doesn't support __vectorcall yet. Reviewed By: Aaron Ballman Differential Revision: http://reviews.llvm.org/D5808 llvm-svn: 220573
2014-10-25 01:42:17 +08:00
case CC_X86VectorCall: Out << 'Q'; break;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
}
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
void MicrosoftCXXNameMangler::mangleCallingConvention(const FunctionType *T) {
mangleCallingConvention(T->getCallConv());
}
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void MicrosoftCXXNameMangler::mangleThrowSpecification(
const FunctionProtoType *FT) {
// <throw-spec> ::= Z # throw(...) (default)
// ::= @ # throw() or __declspec/__attribute__((nothrow))
// ::= <type>+
// NOTE: Since the Microsoft compiler ignores throw specifications, they are
// all actually mangled as 'Z'. (They're ignored because their associated
// functionality isn't implemented, and probably never will be.)
Out << 'Z';
}
void MicrosoftCXXNameMangler::mangleType(const UnresolvedUsingType *T,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers, SourceRange Range) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// Probably should be mangled as a template instantiation; need to see what
// VC does first.
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this unresolved dependent type yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
// <type> ::= <union-type> | <struct-type> | <class-type> | <enum-type>
// <union-type> ::= T <name>
// <struct-type> ::= U <name>
// <class-type> ::= V <name>
[-cxx-abi microsoft] Properly mangle enums 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
2013-12-09 12:28:34 +08:00
// <enum-type> ::= W4 <name>
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const EnumType *T, Qualifiers,
SourceRange) {
[ms-cxxabi] Handle template-template arguments Template-template arguments appear to be a rather simple encoding of the template's templated tag type. llvm-svn: 187751
2013-08-06 06:26:46 +08:00
mangleType(cast<TagType>(T)->getDecl());
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const RecordType *T, Qualifiers,
SourceRange) {
[ms-cxxabi] Handle template-template arguments Template-template arguments appear to be a rather simple encoding of the template's templated tag type. llvm-svn: 187751
2013-08-06 06:26:46 +08:00
mangleType(cast<TagType>(T)->getDecl());
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[ms-cxxabi] Handle template-template arguments Template-template arguments appear to be a rather simple encoding of the template's templated tag type. llvm-svn: 187751
2013-08-06 06:26:46 +08:00
void MicrosoftCXXNameMangler::mangleType(const TagDecl *TD) {
switch (TD->getTagKind()) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
case TTK_Union:
Out << 'T';
break;
case TTK_Struct:
case TTK_Interface:
Out << 'U';
break;
case TTK_Class:
Out << 'V';
break;
case TTK_Enum:
[-cxx-abi microsoft] Properly mangle enums 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
2013-12-09 12:28:34 +08:00
Out << "W4";
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
break;
}
[ms-cxxabi] Handle template-template arguments Template-template arguments appear to be a rather simple encoding of the template's templated tag type. llvm-svn: 187751
2013-08-06 06:26:46 +08:00
mangleName(TD);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
// <type> ::= <array-type>
// <array-type> ::= <pointer-cvr-qualifiers> <cvr-qualifiers>
// [Y <dimension-count> <dimension>+]
[ms-cxxabi] Mangle in an implicit 'E' for certain types on win64 Most of the complexity of this patch is figuring out which types get the qualifier and which don't. If we implement __ptr32/64, then we should check the qualifier instead of assuming all pointers are 64-bit. This fixes PR13792. Patch by Warren Hunt! llvm-svn: 181825
2013-05-15 04:30:42 +08:00
// <element-type> # as global, E is never required
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// It's supposed to be the other way around, but for some strange reason, it
// isn't. Today this behavior is retained for the sole purpose of backwards
// compatibility.
[-cxx-abi microsoft] Canonicalize array parameters better 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
2013-09-11 12:44:30 +08:00
void MicrosoftCXXNameMangler::mangleDecayedArrayType(const ArrayType *T) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// This isn't a recursive mangling, so now we have to do it all in this
// one call.
MS ABI: Refactor extended qualifiers 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
2014-02-18 22:20:10 +08:00
manglePointerCVQualifiers(T->getElementType().getQualifiers());
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
mangleType(T->getElementType(), SourceRange());
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const ConstantArrayType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange) {
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
llvm_unreachable("Should have been special cased");
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const VariableArrayType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange) {
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
llvm_unreachable("Should have been special cased");
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
void MicrosoftCXXNameMangler::mangleType(const DependentSizedArrayType *T,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers, SourceRange) {
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
llvm_unreachable("Should have been special cased");
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
void MicrosoftCXXNameMangler::mangleType(const IncompleteArrayType *T,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers, SourceRange) {
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
llvm_unreachable("Should have been special cased");
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[ms-cxxabi] Use sugared types in the mangler instead of canonical types At this point, it's clear that the MSVC mangler uses the type-as-written instead of the canonical type, so this should bring us closer to MSVC. The main thrust of this change is to fix the way we mangle decayed array parameters of function pointer parameters. With a DecayedType sugar node, this code can now be much simpler. Fixes PR16096. This also fixes a separate issue that Richard spotted in review. Because separate declarations of the same entity can be spelled and mangled differently, MSVC always mangles the earliest declaration in an attempt to avoid link errors. Clang now does the same. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D844 llvm-svn: 184777
2013-06-25 03:21:52 +08:00
void MicrosoftCXXNameMangler::mangleArrayType(const ArrayType *T) {
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
QualType ElementTy(T, 0);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SmallVector<llvm::APInt, 3> Dimensions;
for (;;) {
[MS ABI] Add support for mangling VLA types Treat a VLA type like an incomplete array type. llvm-svn: 235575
2015-04-23 15:42:08 +08:00
if (ElementTy->isConstantArrayType()) {
const ConstantArrayType *CAT =
getASTContext().getAsConstantArrayType(ElementTy);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
Dimensions.push_back(CAT->getSize());
ElementTy = CAT->getElementType();
[MS ABI] Add support for mangling VLA types Treat a VLA type like an incomplete array type. llvm-svn: 235575
2015-04-23 15:42:08 +08:00
} else if (ElementTy->isIncompleteArrayType()) {
const IncompleteArrayType *IAT =
getASTContext().getAsIncompleteArrayType(ElementTy);
Dimensions.push_back(llvm::APInt(32, 0));
ElementTy = IAT->getElementType();
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
} else if (ElementTy->isVariableArrayType()) {
const VariableArrayType *VAT =
getASTContext().getAsVariableArrayType(ElementTy);
[MS ABI] Add support for mangling VLA types Treat a VLA type like an incomplete array type. llvm-svn: 235575
2015-04-23 15:42:08 +08:00
Dimensions.push_back(llvm::APInt(32, 0));
ElementTy = VAT->getElementType();
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
} else if (ElementTy->isDependentSizedArrayType()) {
// The dependent expression has to be folded into a constant (TODO).
const DependentSizedArrayType *DSAT =
getASTContext().getAsDependentSizedArrayType(ElementTy);
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this dependent-length array yet");
Diags.Report(DSAT->getSizeExpr()->getExprLoc(), DiagID)
<< DSAT->getBracketsRange();
return;
[MS ABI] Add support for mangling VLA types Treat a VLA type like an incomplete array type. llvm-svn: 235575
2015-04-23 15:42:08 +08:00
} else {
break;
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
}
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
Out << 'Y';
// <dimension-count> ::= <number> # number of extra dimensions
mangleNumber(Dimensions.size());
MS ABI: Use range-based for loops in the mangler No functional change. llvm-svn: 206945
2014-04-23 13:16:53 +08:00
for (const llvm::APInt &Dimension : Dimensions)
mangleNumber(Dimension.getLimitedValue());
[ms-cxxabi] Use sugared types in the mangler instead of canonical types At this point, it's clear that the MSVC mangler uses the type-as-written instead of the canonical type, so this should bring us closer to MSVC. The main thrust of this change is to fix the way we mangle decayed array parameters of function pointer parameters. With a DecayedType sugar node, this code can now be much simpler. Fixes PR16096. This also fixes a separate issue that Richard spotted in review. Because separate declarations of the same entity can be spelled and mangled differently, MSVC always mangles the earliest declaration in an attempt to avoid link errors. Clang now does the same. Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D844 llvm-svn: 184777
2013-06-25 03:21:52 +08:00
mangleType(ElementTy, SourceRange(), QMM_Escape);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
// <type> ::= <pointer-to-member-type>
// <pointer-to-member-type> ::= <pointer-cvr-qualifiers> <cvr-qualifiers>
// <class name> <type>
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const MemberPointerType *T, Qualifiers Quals,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range) {
QualType PointeeType = T->getPointeeType();
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
manglePointerCVQualifiers(Quals);
manglePointerExtQualifiers(Quals, PointeeType);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
if (const FunctionProtoType *FPT = PointeeType->getAs<FunctionProtoType>()) {
Out << '8';
mangleName(T->getClass()->castAs<RecordType>()->getDecl());
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
mangleFunctionType(FPT, nullptr, true);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
} else {
mangleQualifiers(PointeeType.getQualifiers(), true);
mangleName(T->getClass()->castAs<RecordType>()->getDecl());
[ms-cxxabi] Fix a number of bugs in the mangler. This includes the following fixes: - Implement 4 subtly different variants of qualifier mangling and use them in what I believe are the right places. - Fix handling of array types. Previously we were always decaying them, which is wrong if the type appears as a template argument, pointee, referent etc. Fixes PR13182. Differential Revision: http://llvm-reviews.chandlerc.com/D709 llvm-svn: 180250
2013-04-25 12:25:40 +08:00
mangleType(PointeeType, Range, QMM_Drop);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
}
void MicrosoftCXXNameMangler::mangleType(const TemplateTypeParmType *T,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers, SourceRange Range) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this template type parameter type yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const SubstTemplateTypeParmPackType *T,
Qualifiers, SourceRange Range) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this substituted parameter pack yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
// <type> ::= <pointer-type>
[ms-cxxabi] Mangle in an implicit 'E' for certain types on win64 Most of the complexity of this patch is figuring out which types get the qualifier and which don't. If we implement __ptr32/64, then we should check the qualifier instead of assuming all pointers are 64-bit. This fixes PR13792. Patch by Warren Hunt! llvm-svn: 181825
2013-05-15 04:30:42 +08:00
// <pointer-type> ::= E? <pointer-cvr-qualifiers> <cvr-qualifiers> <type>
Correct hyphenations in comments and assert messages This patch tries to avoid unrelated changes other than fixing a few hyphen-related ambiguities in nearby lines. llvm-svn: 196466
2013-12-05 12:47:09 +08:00
// # the E is required for 64-bit non-static pointers
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const PointerType *T, Qualifiers Quals,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range) {
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
QualType PointeeType = T->getPointeeType();
manglePointerCVQualifiers(Quals);
manglePointerExtQualifiers(Quals, PointeeType);
mangleType(PointeeType, Range);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
void MicrosoftCXXNameMangler::mangleType(const ObjCObjectPointerType *T,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers Quals, SourceRange Range) {
QualType PointeeType = T->getPointeeType();
manglePointerCVQualifiers(Quals);
manglePointerExtQualifiers(Quals, PointeeType);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// Object pointers never have qualifiers.
Out << 'A';
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
mangleType(PointeeType, Range);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
// <type> ::= <reference-type>
[ms-cxxabi] Mangle in an implicit 'E' for certain types on win64 Most of the complexity of this patch is figuring out which types get the qualifier and which don't. If we implement __ptr32/64, then we should check the qualifier instead of assuming all pointers are 64-bit. This fixes PR13792. Patch by Warren Hunt! llvm-svn: 181825
2013-05-15 04:30:42 +08:00
// <reference-type> ::= A E? <cvr-qualifiers> <type>
Correct hyphenations in comments and assert messages This patch tries to avoid unrelated changes other than fixing a few hyphen-related ambiguities in nearby lines. llvm-svn: 196466
2013-12-05 12:47:09 +08:00
// # the E is required for 64-bit non-static lvalue references
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void MicrosoftCXXNameMangler::mangleType(const LValueReferenceType *T,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers Quals, SourceRange Range) {
QualType PointeeType = T->getPointeeType();
Out << (Quals.hasVolatile() ? 'B' : 'A');
manglePointerExtQualifiers(Quals, PointeeType);
mangleType(PointeeType, Range);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
// <type> ::= <r-value-reference-type>
[ms-cxxabi] Mangle in an implicit 'E' for certain types on win64 Most of the complexity of this patch is figuring out which types get the qualifier and which don't. If we implement __ptr32/64, then we should check the qualifier instead of assuming all pointers are 64-bit. This fixes PR13792. Patch by Warren Hunt! llvm-svn: 181825
2013-05-15 04:30:42 +08:00
// <r-value-reference-type> ::= $$Q E? <cvr-qualifiers> <type>
Correct hyphenations in comments and assert messages This patch tries to avoid unrelated changes other than fixing a few hyphen-related ambiguities in nearby lines. llvm-svn: 196466
2013-12-05 12:47:09 +08:00
// # the E is required for 64-bit non-static rvalue references
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
void MicrosoftCXXNameMangler::mangleType(const RValueReferenceType *T,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers Quals, SourceRange Range) {
QualType PointeeType = T->getPointeeType();
Out << (Quals.hasVolatile() ? "$$R" : "$$Q");
manglePointerExtQualifiers(Quals, PointeeType);
mangleType(PointeeType, Range);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const ComplexType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range) {
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this complex number type yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const VectorType *T, Qualifiers Quals,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range) {
[ms-cxxabi] Mangle vector types Summary: The only vector types a user can pass from MSVC code to clang code are the ones from *mmintrin.h, so we only have to match the MSVC mangling for these types. MSVC mangles the __m128 family of types as tag types, which we match. For other vector types, we emit a unique tag type mangling that won't match anything produced by MSVC. Reviewers: rjmccall CC: chandlerc, timurrrr, cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D576 llvm-svn: 178036
2013-03-27 00:56:59 +08:00
const BuiltinType *ET = T->getElementType()->getAs<BuiltinType>();
assert(ET && "vectors with non-builtin elements are unsupported");
uint64_t Width = getASTContext().getTypeSize(T);
// Pattern match exactly the typedefs in our intrinsic headers. Anything that
// doesn't match the Intel types uses a custom mangling below.
[MS ABI] Be a little more defensive wrt vector types We probably shouldn't say that all appropriately sized vector types are intel vector types (i.e. __m128, etc.) as they don't exist for all architectures. While this is largely academic, it'd save some debugging if we supported such a platform. llvm-svn: 238731
2015-06-01 15:41:37 +08:00
bool IsBuiltin = true;
llvm::Triple::ArchType AT =
getASTContext().getTargetInfo().getTriple().getArch();
if (AT == llvm::Triple::x86 || AT == llvm::Triple::x86_64) {
if (Width == 64 && ET->getKind() == BuiltinType::LongLong) {
Out << "T__m64";
} else if (Width >= 128) {
if (ET->getKind() == BuiltinType::Float)
Out << "T__m" << Width;
else if (ET->getKind() == BuiltinType::LongLong)
Out << "T__m" << Width << 'i';
else if (ET->getKind() == BuiltinType::Double)
Out << "U__m" << Width << 'd';
else
IsBuiltin = false;
} else {
IsBuiltin = false;
}
[ms-cxxabi] Mangle vector types Summary: The only vector types a user can pass from MSVC code to clang code are the ones from *mmintrin.h, so we only have to match the MSVC mangling for these types. MSVC mangles the __m128 family of types as tag types, which we match. For other vector types, we emit a unique tag type mangling that won't match anything produced by MSVC. Reviewers: rjmccall CC: chandlerc, timurrrr, cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D576 llvm-svn: 178036
2013-03-27 00:56:59 +08:00
} else {
[MS ABI] Be a little more defensive wrt vector types We probably shouldn't say that all appropriately sized vector types are intel vector types (i.e. __m128, etc.) as they don't exist for all architectures. While this is largely academic, it'd save some debugging if we supported such a platform. llvm-svn: 238731
2015-06-01 15:41:37 +08:00
IsBuiltin = false;
[ms-cxxabi] Mangle vector types Summary: The only vector types a user can pass from MSVC code to clang code are the ones from *mmintrin.h, so we only have to match the MSVC mangling for these types. MSVC mangles the __m128 family of types as tag types, which we match. For other vector types, we emit a unique tag type mangling that won't match anything produced by MSVC. Reviewers: rjmccall CC: chandlerc, timurrrr, cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D576 llvm-svn: 178036
2013-03-27 00:56:59 +08:00
}
[MS ABI] Be a little more defensive wrt vector types We probably shouldn't say that all appropriately sized vector types are intel vector types (i.e. __m128, etc.) as they don't exist for all architectures. While this is largely academic, it'd save some debugging if we supported such a platform. llvm-svn: 238731
2015-06-01 15:41:37 +08:00
if (!IsBuiltin) {
[ms-cxxabi] Mangle vector types Summary: The only vector types a user can pass from MSVC code to clang code are the ones from *mmintrin.h, so we only have to match the MSVC mangling for these types. MSVC mangles the __m128 family of types as tag types, which we match. For other vector types, we emit a unique tag type mangling that won't match anything produced by MSVC. Reviewers: rjmccall CC: chandlerc, timurrrr, cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D576 llvm-svn: 178036
2013-03-27 00:56:59 +08:00
// The MS ABI doesn't have a special mangling for vector types, so we define
// our own mangling to handle uses of __vector_size__ on user-specified
// types, and for extensions like __v4sf.
Out << "T__clang_vec" << T->getNumElements() << '_';
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
mangleType(ET, Quals, Range);
[ms-cxxabi] Mangle vector types Summary: The only vector types a user can pass from MSVC code to clang code are the ones from *mmintrin.h, so we only have to match the MSVC mangling for these types. MSVC mangles the __m128 family of types as tag types, which we match. For other vector types, we emit a unique tag type mangling that won't match anything produced by MSVC. Reviewers: rjmccall CC: chandlerc, timurrrr, cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D576 llvm-svn: 178036
2013-03-27 00:56:59 +08:00
}
Out << "@@";
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[ms-cxxabi] Mangle vector types Summary: The only vector types a user can pass from MSVC code to clang code are the ones from *mmintrin.h, so we only have to match the MSVC mangling for these types. MSVC mangles the __m128 family of types as tag types, which we match. For other vector types, we emit a unique tag type mangling that won't match anything produced by MSVC. Reviewers: rjmccall CC: chandlerc, timurrrr, cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D576 llvm-svn: 178036
2013-03-27 00:56:59 +08:00
[MS ABI] Create a mangling for extended vector types Extended vector types are mangled just like normal vector types. llvm-svn: 243828
2015-08-01 13:51:55 +08:00
void MicrosoftCXXNameMangler::mangleType(const ExtVectorType *T,
Qualifiers Quals, SourceRange Range) {
mangleType(static_cast<const VectorType *>(T), Quals, Range);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
void MicrosoftCXXNameMangler::mangleType(const DependentSizedExtVectorType *T,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers, SourceRange Range) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this dependent-sized extended vector type yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const ObjCInterfaceType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange) {
// ObjC interfaces have structs underlying them.
Out << 'U';
mangleName(T->getDecl());
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const ObjCObjectType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range) {
// We don't allow overloading by different protocol qualification,
// so mangling them isn't necessary.
mangleType(T->getBaseType(), Range);
}
void MicrosoftCXXNameMangler::mangleType(const BlockPointerType *T,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers Quals, SourceRange Range) {
QualType PointeeType = T->getPointeeType();
manglePointerCVQualifiers(Quals);
manglePointerExtQualifiers(Quals, PointeeType);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
Out << "_E";
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
mangleFunctionType(PointeeType->castAs<FunctionProtoType>());
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
Parse: Do not 'HandleTopLevelDecl' on templated functions. Summary: HandleTopLevelDecl on a templated function leads us to try and mangle it. Reviewers: rsmith Reviewed By: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1412 llvm-svn: 188536
2013-08-16 16:29:13 +08:00
void MicrosoftCXXNameMangler::mangleType(const InjectedClassNameType *,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers, SourceRange) {
Parse: Do not 'HandleTopLevelDecl' on templated functions. Summary: HandleTopLevelDecl on a templated function leads us to try and mangle it. Reviewers: rsmith Reviewed By: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1412 llvm-svn: 188536
2013-08-16 16:29:13 +08:00
llvm_unreachable("Cannot mangle injected class name type.");
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
void MicrosoftCXXNameMangler::mangleType(const TemplateSpecializationType *T,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers, SourceRange Range) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this template specialization type yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const DependentNameType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range) {
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this dependent name type yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
void MicrosoftCXXNameMangler::mangleType(
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
const DependentTemplateSpecializationType *T, Qualifiers,
SourceRange Range) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this dependent template specialization type yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const PackExpansionType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range) {
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this pack expansion yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const TypeOfType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range) {
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this typeof(type) yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const TypeOfExprType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range) {
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this typeof(expression) yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const DecltypeType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range) {
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this decltype() yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
void MicrosoftCXXNameMangler::mangleType(const UnaryTransformType *T,
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
Qualifiers, SourceRange Range) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this unary transform type yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const AutoType *T, Qualifiers,
SourceRange Range) {
MSVC ABI: Support C++11's auto on variables 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
2014-01-22 04:33:36 +08:00
assert(T->getDeducedType().isNull() && "expecting a dependent type!");
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this 'auto' type yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
[MS ABI] Implement restrict qualified references MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
2015-05-26 09:30:45 +08:00
void MicrosoftCXXNameMangler::mangleType(const AtomicType *T, Qualifiers,
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
SourceRange Range) {
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this C11 atomic type yet");
Diags.Report(Range.getBegin(), DiagID)
<< Range;
}
On 32 bit windows, mangle stdcall and fastcall decls in clang. 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
2013-10-16 09:40:34 +08:00
void MicrosoftMangleContextImpl::mangleCXXName(const NamedDecl *D,
raw_ostream &Out) {
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
assert((isa<FunctionDecl>(D) || isa<VarDecl>(D)) &&
"Invalid mangleName() call, argument is not a variable or function!");
assert(!isa<CXXConstructorDecl>(D) && !isa<CXXDestructorDecl>(D) &&
"Invalid mangleName() call on 'structor decl!");
PrettyStackTraceDecl CrashInfo(D, SourceLocation(),
getASTContext().getSourceManager(),
"Mangling declaration");
MicrosoftCXXNameMangler Mangler(*this, Out);
return Mangler.mangle(D);
}
Add MicrosoftVFTableContext to AST llvm-svn: 187409
2013-07-30 17:46:19 +08:00
Fix PR17738 - add support for vtordisp thunks when using -cxx-abi microsoft llvm-svn: 194132
2013-11-06 14:24:31 +08:00
// <this-adjustment> ::= <no-adjustment> | <static-adjustment> |
// <virtual-adjustment>
// <no-adjustment> ::= A # private near
// ::= B # private far
// ::= I # protected near
// ::= J # protected far
// ::= Q # public near
// ::= R # public far
// <static-adjustment> ::= G <static-offset> # private near
// ::= H <static-offset> # private far
// ::= O <static-offset> # protected near
// ::= P <static-offset> # protected far
// ::= W <static-offset> # public near
// ::= X <static-offset> # public far
// <virtual-adjustment> ::= $0 <virtual-shift> <static-offset> # private near
// ::= $1 <virtual-shift> <static-offset> # private far
// ::= $2 <virtual-shift> <static-offset> # protected near
// ::= $3 <virtual-shift> <static-offset> # protected far
// ::= $4 <virtual-shift> <static-offset> # public near
// ::= $5 <virtual-shift> <static-offset> # public far
// <virtual-shift> ::= <vtordisp-shift> | <vtordispex-shift>
// <vtordisp-shift> ::= <offset-to-vtordisp>
// <vtordispex-shift> ::= <offset-to-vbptr> <vbase-offset-offset>
// <offset-to-vtordisp>
Reland 192220 "Abstract out parts of thunk emission code, add support for simple thunks when using -cxx-abi microsoft" with relaxed assertions llvm-svn: 192285
2013-10-09 17:23:58 +08:00
static void mangleThunkThisAdjustment(const CXXMethodDecl *MD,
const ThisAdjustment &Adjustment,
MicrosoftCXXNameMangler &Mangler,
raw_ostream &Out) {
Fix PR17738 - add support for vtordisp thunks when using -cxx-abi microsoft llvm-svn: 194132
2013-11-06 14:24:31 +08:00
if (!Adjustment.Virtual.isEmpty()) {
Out << '$';
char AccessSpec;
switch (MD->getAccess()) {
case AS_none:
llvm_unreachable("Unsupported access specifier");
case AS_private:
AccessSpec = '0';
break;
case AS_protected:
AccessSpec = '2';
break;
case AS_public:
AccessSpec = '4';
}
if (Adjustment.Virtual.Microsoft.VBPtrOffset) {
Out << 'R' << AccessSpec;
[-cxx-abi microsoft] Mangle large integral constants correctly 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
2013-12-09 18:44:32 +08:00
Mangler.mangleNumber(
static_cast<uint32_t>(Adjustment.Virtual.Microsoft.VBPtrOffset));
Mangler.mangleNumber(
static_cast<uint32_t>(Adjustment.Virtual.Microsoft.VBOffsetOffset));
Mangler.mangleNumber(
static_cast<uint32_t>(Adjustment.Virtual.Microsoft.VtordispOffset));
Mangler.mangleNumber(static_cast<uint32_t>(Adjustment.NonVirtual));
Fix PR17738 - add support for vtordisp thunks when using -cxx-abi microsoft llvm-svn: 194132
2013-11-06 14:24:31 +08:00
} else {
Out << AccessSpec;
[-cxx-abi microsoft] Mangle large integral constants correctly 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
2013-12-09 18:44:32 +08:00
Mangler.mangleNumber(
static_cast<uint32_t>(Adjustment.Virtual.Microsoft.VtordispOffset));
Mangler.mangleNumber(-static_cast<uint32_t>(Adjustment.NonVirtual));
Fix PR17738 - add support for vtordisp thunks when using -cxx-abi microsoft llvm-svn: 194132
2013-11-06 14:24:31 +08:00
}
} else if (Adjustment.NonVirtual != 0) {
Reland 192220 "Abstract out parts of thunk emission code, add support for simple thunks when using -cxx-abi microsoft" with relaxed assertions llvm-svn: 192285
2013-10-09 17:23:58 +08:00
switch (MD->getAccess()) {
case AS_none:
llvm_unreachable("Unsupported access specifier");
case AS_private:
Out << 'G';
break;
case AS_protected:
Out << 'O';
break;
case AS_public:
Out << 'W';
}
[-cxx-abi microsoft] Mangle large integral constants correctly 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
2013-12-09 18:44:32 +08:00
Mangler.mangleNumber(-static_cast<uint32_t>(Adjustment.NonVirtual));
Reland 192220 "Abstract out parts of thunk emission code, add support for simple thunks when using -cxx-abi microsoft" with relaxed assertions llvm-svn: 192285
2013-10-09 17:23:58 +08:00
} else {
switch (MD->getAccess()) {
case AS_none:
llvm_unreachable("Unsupported access specifier");
case AS_private:
Out << 'A';
break;
case AS_protected:
Out << 'I';
break;
case AS_public:
Out << 'Q';
}
}
}
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
void
MicrosoftMangleContextImpl::mangleVirtualMemPtrThunk(const CXXMethodDecl *MD,
raw_ostream &Out) {
MicrosoftVTableContext *VTContext =
cast<MicrosoftVTableContext>(getASTContext().getVTableContext());
const MicrosoftVTableContext::MethodVFTableLocation &ML =
VTContext->getMethodVFTableLocation(GlobalDecl(MD));
[-cxx-abi microsoft] Emit thunks for pointers to virtual member functions 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
2013-11-16 01:24:45 +08:00
MicrosoftCXXNameMangler Mangler(*this, Out);
MS ABI: Mangle member pointer template arguments 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
2014-02-06 01:27:08 +08:00
Mangler.getStream() << "\01?";
Mangler.mangleVirtualMemPtrThunk(MD, ML);
[-cxx-abi microsoft] Emit thunks for pointers to virtual member functions 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
2013-11-16 01:24:45 +08:00
}
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
void MicrosoftMangleContextImpl::mangleThunk(const CXXMethodDecl *MD,
const ThunkInfo &Thunk,
raw_ostream &Out) {
Add MicrosoftVFTableContext to AST llvm-svn: 187409
2013-07-30 17:46:19 +08:00
MicrosoftCXXNameMangler Mangler(*this, Out);
Out << "\01?";
Mangler.mangleName(MD);
Reland 192220 "Abstract out parts of thunk emission code, add support for simple thunks when using -cxx-abi microsoft" with relaxed assertions llvm-svn: 192285
2013-10-09 17:23:58 +08:00
mangleThunkThisAdjustment(MD, Thunk.This, Mangler, Out);
if (!Thunk.Return.isEmpty())
[C++11] Use 'nullptr'. AST edition. llvm-svn: 208517
2014-05-12 13:36:57 +08:00
assert(Thunk.Method != nullptr &&
"Thunk info should hold the overridee decl");
Reland 192220 "Abstract out parts of thunk emission code, add support for simple thunks when using -cxx-abi microsoft" with relaxed assertions llvm-svn: 192285
2013-10-09 17:23:58 +08:00
const CXXMethodDecl *DeclForFPT = Thunk.Method ? Thunk.Method : MD;
Mangler.mangleFunctionType(
DeclForFPT->getType()->castAs<FunctionProtoType>(), MD);
}
void MicrosoftMangleContextImpl::mangleCXXDtorThunk(
const CXXDestructorDecl *DD, CXXDtorType Type,
const ThisAdjustment &Adjustment, raw_ostream &Out) {
// FIXME: Actually, the dtor thunk should be emitted for vector deleting
// dtors rather than scalar deleting dtors. Just use the vector deleting dtor
// mangling manually until we support both deleting dtor types.
assert(Type == Dtor_Deleting);
MicrosoftCXXNameMangler Mangler(*this, Out, DD, Type);
Out << "\01??_E";
Mangler.mangleName(DD->getParent());
mangleThunkThisAdjustment(DD, Adjustment, Mangler, Out);
Mangler.mangleFunctionType(DD->getType()->castAs<FunctionProtoType>(), DD);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[ms-cxxabi] Emit and install appropriately mangled vbtables In Itanium, dynamic classes have one vtable with several different address points for dynamic base classes that can't share vtables. In the MS C++ ABI, each vbtable that can't be shared gets its own symbol, similar to how ctor vtables work in Itanium. However, instead of mangling the subobject offset into the symbol, the unique portions of the inheritance path are mangled into the symbol to make it unique. This patch implements the MSVC 2012 scheme for forming unique vbtable symbol names. MSVC 2010 use the same mangling with a different subset of the path. Implementing that mangling and possibly others is TODO. Each vbtable is an array of i32 offsets from the vbptr that points to it to another virtual base subobject. The first entry of a vbtable always points to the base of the current subobject, implying that it is the same no matter which parent class contains it. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D636 llvm-svn: 184309
2013-06-19 23:20:38 +08:00
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
void MicrosoftMangleContextImpl::mangleCXXVFTable(
Abstract out the emission of vtables, add basic support for vtable emission when using -cxx-abi microsoft Reviewed at http://llvm-reviews.chandlerc.com/D1532 llvm-svn: 191523
2013-09-27 22:48:01 +08:00
const CXXRecordDecl *Derived, ArrayRef<const CXXRecordDecl *> BasePath,
raw_ostream &Out) {
[ms-cxxabi] Emit and install appropriately mangled vbtables In Itanium, dynamic classes have one vtable with several different address points for dynamic base classes that can't share vtables. In the MS C++ ABI, each vbtable that can't be shared gets its own symbol, similar to how ctor vtables work in Itanium. However, instead of mangling the subobject offset into the symbol, the unique portions of the inheritance path are mangled into the symbol to make it unique. This patch implements the MSVC 2012 scheme for forming unique vbtable symbol names. MSVC 2010 use the same mangling with a different subset of the path. Implementing that mangling and possibly others is TODO. Each vbtable is an array of i32 offsets from the vbptr that points to it to another virtual base subobject. The first entry of a vbtable always points to the base of the current subobject, implying that it is the same no matter which parent class contains it. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D636 llvm-svn: 184309
2013-06-19 23:20:38 +08:00
// <mangled-name> ::= ?_7 <class-name> <storage-class>
// <cvr-qualifiers> [<name>] @
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
// NOTE: <cvr-qualifiers> here is always 'B' (const). <storage-class>
[ms-cxxabi] Emit and install appropriately mangled vbtables In Itanium, dynamic classes have one vtable with several different address points for dynamic base classes that can't share vtables. In the MS C++ ABI, each vbtable that can't be shared gets its own symbol, similar to how ctor vtables work in Itanium. However, instead of mangling the subobject offset into the symbol, the unique portions of the inheritance path are mangled into the symbol to make it unique. This patch implements the MSVC 2012 scheme for forming unique vbtable symbol names. MSVC 2010 use the same mangling with a different subset of the path. Implementing that mangling and possibly others is TODO. Each vbtable is an array of i32 offsets from the vbptr that points to it to another virtual base subobject. The first entry of a vbtable always points to the base of the current subobject, implying that it is the same no matter which parent class contains it. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D636 llvm-svn: 184309
2013-06-19 23:20:38 +08:00
// is always '6' for vftables.
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << "\01??_7";
Abstract out the emission of vtables, add basic support for vtable emission when using -cxx-abi microsoft Reviewed at http://llvm-reviews.chandlerc.com/D1532 llvm-svn: 191523
2013-09-27 22:48:01 +08:00
Mangler.mangleName(Derived);
Mangler.getStream() << "6B"; // '6' for vftable, 'B' for const.
MS ABI: Use range-based for loops in the mangler No functional change. llvm-svn: 206945
2014-04-23 13:16:53 +08:00
for (const CXXRecordDecl *RD : BasePath)
Mangler.mangleName(RD);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
Mangler.getStream() << '@';
}
[ms-cxxabi] Emit and install appropriately mangled vbtables In Itanium, dynamic classes have one vtable with several different address points for dynamic base classes that can't share vtables. In the MS C++ ABI, each vbtable that can't be shared gets its own symbol, similar to how ctor vtables work in Itanium. However, instead of mangling the subobject offset into the symbol, the unique portions of the inheritance path are mangled into the symbol to make it unique. This patch implements the MSVC 2012 scheme for forming unique vbtable symbol names. MSVC 2010 use the same mangling with a different subset of the path. Implementing that mangling and possibly others is TODO. Each vbtable is an array of i32 offsets from the vbptr that points to it to another virtual base subobject. The first entry of a vbtable always points to the base of the current subobject, implying that it is the same no matter which parent class contains it. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D636 llvm-svn: 184309
2013-06-19 23:20:38 +08:00
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
void MicrosoftMangleContextImpl::mangleCXXVBTable(
[ms-cxxabi] Emit and install appropriately mangled vbtables In Itanium, dynamic classes have one vtable with several different address points for dynamic base classes that can't share vtables. In the MS C++ ABI, each vbtable that can't be shared gets its own symbol, similar to how ctor vtables work in Itanium. However, instead of mangling the subobject offset into the symbol, the unique portions of the inheritance path are mangled into the symbol to make it unique. This patch implements the MSVC 2012 scheme for forming unique vbtable symbol names. MSVC 2010 use the same mangling with a different subset of the path. Implementing that mangling and possibly others is TODO. Each vbtable is an array of i32 offsets from the vbptr that points to it to another virtual base subobject. The first entry of a vbtable always points to the base of the current subobject, implying that it is the same no matter which parent class contains it. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D636 llvm-svn: 184309
2013-06-19 23:20:38 +08:00
const CXXRecordDecl *Derived, ArrayRef<const CXXRecordDecl *> BasePath,
raw_ostream &Out) {
// <mangled-name> ::= ?_8 <class-name> <storage-class>
// <cvr-qualifiers> [<name>] @
// NOTE: <cvr-qualifiers> here is always 'B' (const). <storage-class>
// is always '7' for vbtables.
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << "\01??_8";
Mangler.mangleName(Derived);
Mangler.getStream() << "7B"; // '7' for vbtable, 'B' for const.
MS ABI: Use range-based for loops in the mangler No functional change. llvm-svn: 206945
2014-04-23 13:16:53 +08:00
for (const CXXRecordDecl *RD : BasePath)
Mangler.mangleName(RD);
[ms-cxxabi] Emit and install appropriately mangled vbtables In Itanium, dynamic classes have one vtable with several different address points for dynamic base classes that can't share vtables. In the MS C++ ABI, each vbtable that can't be shared gets its own symbol, similar to how ctor vtables work in Itanium. However, instead of mangling the subobject offset into the symbol, the unique portions of the inheritance path are mangled into the symbol to make it unique. This patch implements the MSVC 2012 scheme for forming unique vbtable symbol names. MSVC 2010 use the same mangling with a different subset of the path. Implementing that mangling and possibly others is TODO. Each vbtable is an array of i32 offsets from the vbptr that points to it to another virtual base subobject. The first entry of a vbtable always points to the base of the current subobject, implying that it is the same no matter which parent class contains it. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D636 llvm-svn: 184309
2013-06-19 23:20:38 +08:00
Mangler.getStream() << '@';
}
MS ABI: Preliminary RTTI mangling Implement what we currently believe is the mangling scheme for RTTI data. Tests will be added in a later commit which actually generate RTTI data. llvm-svn: 208661
2014-05-13 08:44:44 +08:00
void MicrosoftMangleContextImpl::mangleCXXRTTI(QualType T, raw_ostream &Out) {
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << "\01??_R0";
Mangler.mangleType(T, SourceRange(), MicrosoftCXXNameMangler::QMM_Result);
Mangler.getStream() << "@8";
}
void MicrosoftMangleContextImpl::mangleCXXRTTIName(QualType T,
raw_ostream &Out) {
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << '.';
Mangler.mangleType(T, SourceRange(), MicrosoftCXXNameMangler::QMM_Result);
}
[MS ABI] Rework .xdata HandlerType emission Utilizing IMAGEREL relocations for synthetic IR constructs isn't valuable, just clutter. While we are here, simplify HandlerType names by making the numeric value for the 'adjective' part of the mangled name instead of appending '.const', etc. The old scheme made for very long global names and leads to wordy things like '.std_bad_alloc' llvm-svn: 233503
2015-03-30 05:55:10 +08:00
void MicrosoftMangleContextImpl::mangleCXXCatchHandlerType(QualType T,
uint32_t Flags,
raw_ostream &Out) {
MS ABI: Emit HandlerMap entries for C++ catch The HandlerMap describes, to the runtime, what sort of catches surround the try. In principle, this structure has to be emitted by the backend because only it knows the layout of the stack (the runtime needs to know where on the stack the destination of a copy lives, etc.) but there is some C++ specific information that the backend can't reason about. Stick this information in special LLVM globals with the relevant "const", "volatile", "reference" info mangled into the name. llvm-svn: 232538
2015-03-18 04:35:05 +08:00
MicrosoftCXXNameMangler Mangler(*this, Out);
[MS ABI] Rework .xdata HandlerType emission Utilizing IMAGEREL relocations for synthetic IR constructs isn't valuable, just clutter. While we are here, simplify HandlerType names by making the numeric value for the 'adjective' part of the mangled name instead of appending '.const', etc. The old scheme made for very long global names and leads to wordy things like '.std_bad_alloc' llvm-svn: 233503
2015-03-30 05:55:10 +08:00
Mangler.getStream() << "llvm.eh.handlertype.";
MS ABI: Emit HandlerMap entries for C++ catch The HandlerMap describes, to the runtime, what sort of catches surround the try. In principle, this structure has to be emitted by the backend because only it knows the layout of the stack (the runtime needs to know where on the stack the destination of a copy lives, etc.) but there is some C++ specific information that the backend can't reason about. Stick this information in special LLVM globals with the relevant "const", "volatile", "reference" info mangled into the name. llvm-svn: 232538
2015-03-18 04:35:05 +08:00
Mangler.mangleType(T, SourceRange(), MicrosoftCXXNameMangler::QMM_Result);
[MS ABI] Rework .xdata HandlerType emission Utilizing IMAGEREL relocations for synthetic IR constructs isn't valuable, just clutter. While we are here, simplify HandlerType names by making the numeric value for the 'adjective' part of the mangled name instead of appending '.const', etc. The old scheme made for very long global names and leads to wordy things like '.std_bad_alloc' llvm-svn: 233503
2015-03-30 05:55:10 +08:00
Mangler.getStream() << '.' << Flags;
MS ABI: Emit HandlerMap entries for C++ catch The HandlerMap describes, to the runtime, what sort of catches surround the try. In principle, this structure has to be emitted by the backend because only it knows the layout of the stack (the runtime needs to know where on the stack the destination of a copy lives, etc.) but there is some C++ specific information that the backend can't reason about. Stick this information in special LLVM globals with the relevant "const", "volatile", "reference" info mangled into the name. llvm-svn: 232538
2015-03-18 04:35:05 +08:00
}
[MS ABI] Rework member pointer conversion Member pointers in the MS ABI are made complicated due to the following: - Virtual methods in the most derived class (MDC) might live in a vftable in a virtual base. - There are four different representations of member pointer: single inheritance, multiple inheritance, virtual inheritance and the "most general" representation. - Bases might have a *more* general representation than classes which derived from them, a most surprising result. We believed that we could treat all member pointers as-if they were a degenerate case of the multiple inheritance model. This fell apart once we realized that implementing standard member pointers using this ABI requires referencing members with a non-zero vbindex. On a bright note, all but the virtual inheritance model operate rather similarly. The virtual inheritance member pointer representation awkwardly requires a virtual base adjustment in order to refer to entities in the MDC. However, the first virtual base might be quite far from the start of the virtual base. This means that we must add a negative non-virtual displacement. However, things get even more complicated. The most general representation interprets vbindex zero differently from the virtual inheritance model: it doesn't reference the vbtable at all. It turns out that this complexity can increase for quite some time: consider a derived to base conversion from the most general model to the multiple inheritance model... To manage this complexity we introduce a concept of "normalized" member pointer which allows us to treat all three models as the most general model. Then we try to figure out how to map this generalized member pointer onto the destination member pointer model. I've done my best to furnish the code with comments explaining why each adjustment is performed. This fixes PR23878. llvm-svn: 240384
2015-06-23 15:31:11 +08:00
void MicrosoftMangleContextImpl::mangleCXXVirtualDisplacementMap(
const CXXRecordDecl *SrcRD, const CXXRecordDecl *DstRD, raw_ostream &Out) {
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << "\01??_K";
Mangler.mangleName(SrcRD);
Mangler.getStream() << "$C";
Mangler.mangleName(DstRD);
}
MS ABI: Implement support for throwing a C++ exception Throwing a C++ exception, under the MS ABI, is implemented using three components: - ThrowInfo structure which contains information like CV qualifiers, what destructor to call and a pointer to the CatchableTypeArray. - In a significant departure from the Itanium ABI, copying by-value occurs in the runtime and not at the catch site. This means we need to enumerate all possible types that this exception could be caught as and encode the necessary information to convert from the exception object's type to the catch handler's type. This includes complicated derived to base conversions and the execution of copy-constructors. N.B. This implementation doesn't support the execution of a copy-constructor from within the runtime for now. Adding support for that functionality is quite difficult due to things like default argument expressions which may evaluate arbitrary code hiding in the copy-constructor's parameters. Differential Revision: http://reviews.llvm.org/D8066 llvm-svn: 231328
2015-03-05 08:46:22 +08:00
void MicrosoftMangleContextImpl::mangleCXXThrowInfo(QualType T,
bool IsConst,
bool IsVolatile,
uint32_t NumEntries,
raw_ostream &Out) {
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << "_TI";
if (IsConst)
Mangler.getStream() << 'C';
if (IsVolatile)
Mangler.getStream() << 'V';
Mangler.getStream() << NumEntries;
Mangler.mangleType(T, SourceRange(), MicrosoftCXXNameMangler::QMM_Result);
}
void MicrosoftMangleContextImpl::mangleCXXCatchableTypeArray(
QualType T, uint32_t NumEntries, raw_ostream &Out) {
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << "_CTA";
Mangler.getStream() << NumEntries;
Mangler.mangleType(T, SourceRange(), MicrosoftCXXNameMangler::QMM_Result);
}
MS ABI: Insert copy-constructors into the CatchableType Find all unambiguous public classes of the exception object's class type and reference all of their copy constructors. Yes, this is not conforming but it is necessary in order to implement their ABI. This is because the copy constructor is actually referenced by the metadata describing which catch handlers are eligible to handle the exception object. N.B. This doesn't yet handle the copy constructor closure case yet, that work is ongoing. Differential Revision: http://reviews.llvm.org/D8101 llvm-svn: 231499
2015-03-07 02:53:55 +08:00
void MicrosoftMangleContextImpl::mangleCXXCatchableType(
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
QualType T, const CXXConstructorDecl *CD, CXXCtorType CT, uint32_t Size,
uint32_t NVOffset, int32_t VBPtrOffset, uint32_t VBIndex,
raw_ostream &Out) {
MS ABI: Implement support for throwing a C++ exception Throwing a C++ exception, under the MS ABI, is implemented using three components: - ThrowInfo structure which contains information like CV qualifiers, what destructor to call and a pointer to the CatchableTypeArray. - In a significant departure from the Itanium ABI, copying by-value occurs in the runtime and not at the catch site. This means we need to enumerate all possible types that this exception could be caught as and encode the necessary information to convert from the exception object's type to the catch handler's type. This includes complicated derived to base conversions and the execution of copy-constructors. N.B. This implementation doesn't support the execution of a copy-constructor from within the runtime for now. Adding support for that functionality is quite difficult due to things like default argument expressions which may evaluate arbitrary code hiding in the copy-constructor's parameters. Differential Revision: http://reviews.llvm.org/D8066 llvm-svn: 231328
2015-03-05 08:46:22 +08:00
MicrosoftCXXNameMangler Mangler(*this, Out);
MS ABI: Insert copy-constructors into the CatchableType Find all unambiguous public classes of the exception object's class type and reference all of their copy constructors. Yes, this is not conforming but it is necessary in order to implement their ABI. This is because the copy constructor is actually referenced by the metadata describing which catch handlers are eligible to handle the exception object. N.B. This doesn't yet handle the copy constructor closure case yet, that work is ongoing. Differential Revision: http://reviews.llvm.org/D8101 llvm-svn: 231499
2015-03-07 02:53:55 +08:00
Mangler.getStream() << "_CT";
llvm::SmallString<64> RTTIMangling;
{
llvm::raw_svector_ostream Stream(RTTIMangling);
mangleCXXRTTI(T, Stream);
}
Mangler.getStream() << RTTIMangling.substr(1);
MS ABI: Mangle the location of the catchable type into it's name Because the catchable type has a reference to its name, mangle the location to ensure that two catchable types with different locations are distinct. llvm-svn: 231819
2015-03-11 03:01:51 +08:00
// VS2015 CTP6 omits the copy-constructor in the mangled name. This name is,
// in fact, superfluous but I'm not sure the change was made consciously.
// TODO: Revisit this when VS2015 gets released.
MS ABI: Insert copy-constructors into the CatchableType Find all unambiguous public classes of the exception object's class type and reference all of their copy constructors. Yes, this is not conforming but it is necessary in order to implement their ABI. This is because the copy constructor is actually referenced by the metadata describing which catch handlers are eligible to handle the exception object. N.B. This doesn't yet handle the copy constructor closure case yet, that work is ongoing. Differential Revision: http://reviews.llvm.org/D8101 llvm-svn: 231499
2015-03-07 02:53:55 +08:00
llvm::SmallString<64> CopyCtorMangling;
if (CD) {
llvm::raw_svector_ostream Stream(CopyCtorMangling);
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
mangleCXXCtor(CD, CT, Stream);
MS ABI: Insert copy-constructors into the CatchableType Find all unambiguous public classes of the exception object's class type and reference all of their copy constructors. Yes, this is not conforming but it is necessary in order to implement their ABI. This is because the copy constructor is actually referenced by the metadata describing which catch handlers are eligible to handle the exception object. N.B. This doesn't yet handle the copy constructor closure case yet, that work is ongoing. Differential Revision: http://reviews.llvm.org/D8101 llvm-svn: 231499
2015-03-07 02:53:55 +08:00
}
Mangler.getStream() << CopyCtorMangling.substr(1);
MS ABI: Implement support for throwing a C++ exception Throwing a C++ exception, under the MS ABI, is implemented using three components: - ThrowInfo structure which contains information like CV qualifiers, what destructor to call and a pointer to the CatchableTypeArray. - In a significant departure from the Itanium ABI, copying by-value occurs in the runtime and not at the catch site. This means we need to enumerate all possible types that this exception could be caught as and encode the necessary information to convert from the exception object's type to the catch handler's type. This includes complicated derived to base conversions and the execution of copy-constructors. N.B. This implementation doesn't support the execution of a copy-constructor from within the runtime for now. Adding support for that functionality is quite difficult due to things like default argument expressions which may evaluate arbitrary code hiding in the copy-constructor's parameters. Differential Revision: http://reviews.llvm.org/D8066 llvm-svn: 231328
2015-03-05 08:46:22 +08:00
Mangler.getStream() << Size;
MS ABI: Mangle the location of the catchable type into it's name Because the catchable type has a reference to its name, mangle the location to ensure that two catchable types with different locations are distinct. llvm-svn: 231819
2015-03-11 03:01:51 +08:00
if (VBPtrOffset == -1) {
if (NVOffset) {
Mangler.getStream() << NVOffset;
}
} else {
Mangler.getStream() << NVOffset;
Mangler.getStream() << VBPtrOffset;
Mangler.getStream() << VBIndex;
}
MS ABI: Implement support for throwing a C++ exception Throwing a C++ exception, under the MS ABI, is implemented using three components: - ThrowInfo structure which contains information like CV qualifiers, what destructor to call and a pointer to the CatchableTypeArray. - In a significant departure from the Itanium ABI, copying by-value occurs in the runtime and not at the catch site. This means we need to enumerate all possible types that this exception could be caught as and encode the necessary information to convert from the exception object's type to the catch handler's type. This includes complicated derived to base conversions and the execution of copy-constructors. N.B. This implementation doesn't support the execution of a copy-constructor from within the runtime for now. Adding support for that functionality is quite difficult due to things like default argument expressions which may evaluate arbitrary code hiding in the copy-constructor's parameters. Differential Revision: http://reviews.llvm.org/D8066 llvm-svn: 231328
2015-03-05 08:46:22 +08:00
}
MS ABI: Preliminary RTTI mangling Implement what we currently believe is the mangling scheme for RTTI data. Tests will be added in a later commit which actually generate RTTI data. llvm-svn: 208661
2014-05-13 08:44:44 +08:00
void MicrosoftMangleContextImpl::mangleCXXRTTIBaseClassDescriptor(
[MS-ABI] Implements MS-compatible RTTI Enables the emission of MS-compatible RTTI data structures for use with typeid, dynamic_cast and exceptions. Does not implement dynamic_cast or exceptions. As an artiface, typeid works in some cases but proper support an testing will coming in a subsequent patch. majnemer has fuzzed the results. Test cases included. Differential Revision: http://reviews.llvm.org/D3833 llvm-svn: 209523
2014-05-24 00:07:43 +08:00
const CXXRecordDecl *Derived, uint32_t NVOffset, int32_t VBPtrOffset,
MS ABI: Tighten RTTI mangling r208661 contained WIP code, commit the *actual* manglings. llvm-svn: 208668
2014-05-13 14:57:43 +08:00
uint32_t VBTableOffset, uint32_t Flags, raw_ostream &Out) {
MS ABI: Preliminary RTTI mangling Implement what we currently believe is the mangling scheme for RTTI data. Tests will be added in a later commit which actually generate RTTI data. llvm-svn: 208661
2014-05-13 08:44:44 +08:00
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << "\01??_R1";
Mangler.mangleNumber(NVOffset);
Mangler.mangleNumber(VBPtrOffset);
Mangler.mangleNumber(VBTableOffset);
Mangler.mangleNumber(Flags);
MS ABI: Tighten RTTI mangling r208661 contained WIP code, commit the *actual* manglings. llvm-svn: 208668
2014-05-13 14:57:43 +08:00
Mangler.mangleName(Derived);
[MS-ABI] Implements MS-compatible RTTI Enables the emission of MS-compatible RTTI data structures for use with typeid, dynamic_cast and exceptions. Does not implement dynamic_cast or exceptions. As an artiface, typeid works in some cases but proper support an testing will coming in a subsequent patch. majnemer has fuzzed the results. Test cases included. Differential Revision: http://reviews.llvm.org/D3833 llvm-svn: 209523
2014-05-24 00:07:43 +08:00
Mangler.getStream() << "8";
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
MS ABI: Preliminary RTTI mangling Implement what we currently believe is the mangling scheme for RTTI data. Tests will be added in a later commit which actually generate RTTI data. llvm-svn: 208661
2014-05-13 08:44:44 +08:00
void MicrosoftMangleContextImpl::mangleCXXRTTIBaseClassArray(
const CXXRecordDecl *Derived, raw_ostream &Out) {
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << "\01??_R2";
Mangler.mangleName(Derived);
[MS-ABI] Implements MS-compatible RTTI Enables the emission of MS-compatible RTTI data structures for use with typeid, dynamic_cast and exceptions. Does not implement dynamic_cast or exceptions. As an artiface, typeid works in some cases but proper support an testing will coming in a subsequent patch. majnemer has fuzzed the results. Test cases included. Differential Revision: http://reviews.llvm.org/D3833 llvm-svn: 209523
2014-05-24 00:07:43 +08:00
Mangler.getStream() << "8";
MS ABI: Preliminary RTTI mangling Implement what we currently believe is the mangling scheme for RTTI data. Tests will be added in a later commit which actually generate RTTI data. llvm-svn: 208661
2014-05-13 08:44:44 +08:00
}
void MicrosoftMangleContextImpl::mangleCXXRTTIClassHierarchyDescriptor(
const CXXRecordDecl *Derived, raw_ostream &Out) {
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << "\01??_R3";
Mangler.mangleName(Derived);
[MS-ABI] Implements MS-compatible RTTI Enables the emission of MS-compatible RTTI data structures for use with typeid, dynamic_cast and exceptions. Does not implement dynamic_cast or exceptions. As an artiface, typeid works in some cases but proper support an testing will coming in a subsequent patch. majnemer has fuzzed the results. Test cases included. Differential Revision: http://reviews.llvm.org/D3833 llvm-svn: 209523
2014-05-24 00:07:43 +08:00
Mangler.getStream() << "8";
MS ABI: Preliminary RTTI mangling Implement what we currently believe is the mangling scheme for RTTI data. Tests will be added in a later commit which actually generate RTTI data. llvm-svn: 208661
2014-05-13 08:44:44 +08:00
}
void MicrosoftMangleContextImpl::mangleCXXRTTICompleteObjectLocator(
MS ABI: Tighten RTTI mangling r208661 contained WIP code, commit the *actual* manglings. llvm-svn: 208668
2014-05-13 14:57:43 +08:00
const CXXRecordDecl *Derived, ArrayRef<const CXXRecordDecl *> BasePath,
raw_ostream &Out) {
// <mangled-name> ::= ?_R4 <class-name> <storage-class>
// <cvr-qualifiers> [<name>] @
// NOTE: <cvr-qualifiers> here is always 'B' (const). <storage-class>
// is always '6' for vftables.
MS ABI: Preliminary RTTI mangling Implement what we currently believe is the mangling scheme for RTTI data. Tests will be added in a later commit which actually generate RTTI data. llvm-svn: 208661
2014-05-13 08:44:44 +08:00
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << "\01??_R4";
Mangler.mangleName(Derived);
MS ABI: Tighten RTTI mangling r208661 contained WIP code, commit the *actual* manglings. llvm-svn: 208668
2014-05-13 14:57:43 +08:00
Mangler.getStream() << "6B"; // '6' for vftable, 'B' for const.
for (const CXXRecordDecl *RD : BasePath)
Mangler.mangleName(RD);
Mangler.getStream() << '@';
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
Initial support for Win64 SEH IR emission The lowering looks a lot like normal EH lowering, with the exception that the exceptions are caught by executing filter expression code instead of matching typeinfo globals. The filter expressions are outlined into functions which are used in landingpad clauses where typeinfo would normally go. Major aspects that still need work: - Non-call exceptions in __try bodies won't work yet. The plan is to outline the __try block in the frontend to keep things simple. - Filter expressions cannot use local variables until capturing is implemented. - __finally blocks will not run after exceptions. Fixing this requires work in the LLVM SEH preparation pass. The IR lowering looks like this: // C code: bool safe_div(int n, int d, int *r) { __try { *r = normal_div(n, d); } __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) { return false; } return true; } ; LLVM IR: define i32 @filter(i8* %e, i8* %fp) { %ehptrs = bitcast i8* %e to i32** %ehrec = load i32** %ehptrs %code = load i32* %ehrec %matches = icmp eq i32 %code, i32 u0xC0000094 %matches.i32 = zext i1 %matches to i32 ret i32 %matches.i32 } define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) { %rr = invoke i32 @normal_div(i32 %n, i32 %d) to label %normal unwind to label %lpad normal: store i32 %rr, i32* %r ret i1 1 lpad: %ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*) %ehptr = extractvalue {i8*, i32} %ehvals, i32 0 %sel = extractvalue {i8*, i32} %ehvals, i32 1 %filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*)) %matches = icmp eq i32 %sel, %filter_sel br i1 %matches, label %eh.except, label %eh.resume eh.except: ret i1 false eh.resume: resume } Reviewers: rjmccall, rsmith, majnemer Differential Revision: http://reviews.llvm.org/D5607 llvm-svn: 226760
2015-01-22 09:36:17 +08:00
void MicrosoftMangleContextImpl::mangleSEHFilterExpression(
const NamedDecl *EnclosingDecl, raw_ostream &Out) {
MicrosoftCXXNameMangler Mangler(*this, Out);
// The function body is in the same comdat as the function with the handler,
// so the numbering here doesn't have to be the same across TUs.
//
// <mangled-name> ::= ?filt$ <filter-number> @0
Mangler.getStream() << "\01?filt$" << SEHFilterIds[EnclosingDecl]++ << "@0@";
Mangler.mangleName(EnclosingDecl);
}
Reland r234613 (and follow-ups 234614, 234616, 234618) The frameescape intrinsic cannot be inlined, so I fixed the inliner in r234937. This should address PR23216. llvm-svn: 234942
2015-04-15 04:59:00 +08:00
void MicrosoftMangleContextImpl::mangleSEHFinallyBlock(
const NamedDecl *EnclosingDecl, raw_ostream &Out) {
MicrosoftCXXNameMangler Mangler(*this, Out);
// The function body is in the same comdat as the function with the handler,
// so the numbering here doesn't have to be the same across TUs.
//
// <mangled-name> ::= ?fin$ <filter-number> @0
Mangler.getStream() << "\01?fin$" << SEHFinallyIds[EnclosingDecl]++ << "@0@";
Mangler.mangleName(EnclosingDecl);
}
Add a mangler entry point for TBAA rather than using RTTI directly 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
2013-11-20 07:23:00 +08:00
void MicrosoftMangleContextImpl::mangleTypeName(QualType T, raw_ostream &Out) {
// This is just a made up unique string for the purposes of tbaa. undname
// does *not* know how to demangle it.
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << '?';
Mangler.mangleType(T, SourceRange());
}
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
void MicrosoftMangleContextImpl::mangleCXXCtor(const CXXConstructorDecl *D,
CXXCtorType Type,
raw_ostream &Out) {
MS ABI: Implement copy-ctor closures, finish implementing throw This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
2015-03-12 02:36:39 +08:00
MicrosoftCXXNameMangler mangler(*this, Out, D, Type);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
mangler.mangle(D);
}
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
void MicrosoftMangleContextImpl::mangleCXXDtor(const CXXDestructorDecl *D,
CXXDtorType Type,
raw_ostream &Out) {
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
MicrosoftCXXNameMangler mangler(*this, Out, D, Type);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
mangler.mangle(D);
}
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
void MicrosoftMangleContextImpl::mangleReferenceTemporary(const VarDecl *VD,
AST: Mangle reference temporaries reliably Summary: Previously, we would generate a single name for all reference temporaries and allow LLVM to rename them for us. Instead, number the reference temporaries as we build them in Sema. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3554 llvm-svn: 207776
2014-05-02 01:50:17 +08:00
unsigned,
Revert "[-cxx-abi microsoft] Mangle reference temporaries" 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
2013-12-13 08:39:38 +08:00
raw_ostream &) {
unsigned DiagID = getDiags().getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this reference temporary yet");
getDiags().Report(VD->getLocation(), DiagID);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}
[MS ABI] Implement thread-safe initialization using the MSVC 2015 ABI The MSVC 2015 ABI utilizes a rather straightforward adaptation of the algorithm found in the appendix of N2382. While we are here, implement support for emitting cleanups if an exception is thrown while we are intitializing a static local variable. llvm-svn: 236697
2015-05-07 14:15:46 +08:00
void MicrosoftMangleContextImpl::mangleThreadSafeStaticGuardVariable(
const VarDecl *VD, unsigned GuardNum, raw_ostream &Out) {
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << "\01?$TSS" << GuardNum << '@';
Mangler.mangleNestedName(VD);
}
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
void MicrosoftMangleContextImpl::mangleStaticGuardVariable(const VarDecl *VD,
raw_ostream &Out) {
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
// <guard-name> ::= ?_B <postfix> @5 <scope-depth>
[MS ABI] Make sure we number thread_local statics seperately The thread_local variables need their own numbers, they can't share with the other static local variables. llvm-svn: 236774
2015-05-08 05:19:06 +08:00
// ::= ?__J <postfix> @5 <scope-depth>
[ms-cxxabi] Implement guard variables for static initialization 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
2013-09-11 04:14:30 +08:00
// ::= ?$S <guard-num> @ <postfix> @4IA
// The first mangling is what MSVC uses to guard static locals in inline
// functions. It uses a different mangling in external functions to support
// guarding more than 32 variables. MSVC rejects inline functions with more
// than 32 static locals. We don't fully implement the second mangling
// because those guards are not externally visible, and instead use LLVM's
// default renaming when creating a new guard variable.
MicrosoftCXXNameMangler Mangler(*this, Out);
bool Visible = VD->isExternallyVisible();
[MS ABI] Implement thread-safe initialization using the MSVC 2015 ABI The MSVC 2015 ABI utilizes a rather straightforward adaptation of the algorithm found in the appendix of N2382. While we are here, implement support for emitting cleanups if an exception is thrown while we are intitializing a static local variable. llvm-svn: 236697
2015-05-07 14:15:46 +08:00
if (Visible) {
[MS ABI] Make sure we number thread_local statics seperately The thread_local variables need their own numbers, they can't share with the other static local variables. llvm-svn: 236774
2015-05-08 05:19:06 +08:00
Mangler.getStream() << (VD->getTLSKind() ? "\01??__J" : "\01??_B");
[MS ABI] Implement thread-safe initialization using the MSVC 2015 ABI The MSVC 2015 ABI utilizes a rather straightforward adaptation of the algorithm found in the appendix of N2382. While we are here, implement support for emitting cleanups if an exception is thrown while we are intitializing a static local variable. llvm-svn: 236697
2015-05-07 14:15:46 +08:00
} else {
Mangler.getStream() << "\01?$S1@";
}
MS ABI: Disambiguate the manglings for global guard variables If a guard variable will be created for an entity at global scope, then we cannot rely on the scope depth to disambiguate names for us. Instead, mangle the entire variable into the guard to ensure it's uniqueness. llvm-svn: 203151
2014-03-07 03:57:36 +08:00
unsigned ScopeDepth = 0;
if (Visible && !getNextDiscriminator(VD, ScopeDepth))
// If we do not have a discriminator and are emitting a guard variable for
// use at global scope, then mangling the nested name will not be enough to
// remove ambiguities.
Mangler.mangle(VD, "");
else
Mangler.mangleNestedName(VD);
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
Mangler.getStream() << (Visible ? "@5" : "@4IA");
MS ABI: Disambiguate the manglings for global guard variables If a guard variable will be created for an entity at global scope, then we cannot rely on the scope depth to disambiguate names for us. Instead, mangle the entire variable into the guard to ensure it's uniqueness. llvm-svn: 203151
2014-03-07 03:57:36 +08:00
if (ScopeDepth)
[-cxx-abi microsoft] Implement local manglings accurately 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
2014-03-05 16:57:59 +08:00
Mangler.mangleNumber(ScopeDepth);
[ms-cxxabi] Implement guard variables for static initialization 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
2013-09-11 04:14:30 +08:00
}
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
void MicrosoftMangleContextImpl::mangleInitFiniStub(const VarDecl *D,
raw_ostream &Out,
char CharCode) {
[ms-cxxabi] Implement guard variables for static initialization 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
2013-09-11 04:14:30 +08:00
MicrosoftCXXNameMangler Mangler(*this, Out);
[ms-cxxabi] Mangle dynamic initializer stubs the same way MSVC does 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
2013-09-11 04:43:12 +08:00
Mangler.getStream() << "\01??__" << CharCode;
[ms-cxxabi] Implement guard variables for static initialization 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
2013-09-11 04:14:30 +08:00
Mangler.mangleName(D);
MS ABI: Fix the initializer/finalizer mangling for static data members Initializers and finalizers for static data members have the variable's access-specifier, storage-class, type and CV-qualifiers mangled in. llvm-svn: 203145
2014-03-07 03:10:27 +08:00
if (D->isStaticDataMember()) {
Mangler.mangleVariableEncoding(D);
Mangler.getStream() << '@';
}
[ms-cxxabi] Mangle dynamic initializer stubs the same way MSVC does 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
2013-09-11 04:43:12 +08:00
// This is the function class mangling. These stubs are global, non-variadic,
// cdecl functions that return void and take no args.
[ms-cxxabi] Implement guard variables for static initialization 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
2013-09-11 04:14:30 +08:00
Mangler.getStream() << "YAXXZ";
}
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
void MicrosoftMangleContextImpl::mangleDynamicInitializer(const VarDecl *D,
raw_ostream &Out) {
[ms-cxxabi] Mangle dynamic initializer stubs the same way MSVC does 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
2013-09-11 04:43:12 +08:00
// <initializer-name> ::= ?__E <name> YAXXZ
mangleInitFiniStub(D, Out, 'E');
}
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
void
MicrosoftMangleContextImpl::mangleDynamicAtExitDestructor(const VarDecl *D,
raw_ostream &Out) {
[ms-cxxabi] Mangle dynamic initializer stubs the same way MSVC does 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
2013-09-11 04:43:12 +08:00
// <destructor-name> ::= ?__F <name> YAXXZ
mangleInitFiniStub(D, Out, 'F');
}
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
void MicrosoftMangleContextImpl::mangleStringLiteral(const StringLiteral *SL,
raw_ostream &Out) {
// <char-type> ::= 0 # char
// ::= 1 # wchar_t
// ::= ??? # char16_t/char32_t will need a mangling too...
//
// <literal-length> ::= <non-negative integer> # the length of the literal
//
// <encoded-crc> ::= <hex digit>+ @ # crc of the literal including
// # null-terminator
//
// <encoded-string> ::= <simple character> # uninteresting character
// ::= '?$' <hex digit> <hex digit> # these two nibbles
// # encode the byte for the
// # character
// ::= '?' [a-z] # \xe1 - \xfa
// ::= '?' [A-Z] # \xc1 - \xda
// ::= '?' [0-9] # [,/\:. \n\t'-]
//
// <literal> ::= '??_C@_' <char-type> <literal-length> <encoded-crc>
// <encoded-string> '@'
MicrosoftCXXNameMangler Mangler(*this, Out);
Mangler.getStream() << "\01??_C@_";
// <char-type>: The "kind" of string literal is encoded into the mangled name.
MS ABI: Mangle char16_t and char32_t string literals We previously had support for char and wchar_t string literals. VS 2015 added support for char16_t and char32_t. String literals must be mangled in the MS ABI in order for them to be deduplicated across translation units: their linker has no notion of mergeable section. Instead, they use the mangled name to make a COMDAT for the string literal; the COMDAT will merge with other COMDATs in other object files. This allows strings in object files generated by clang to get merged with strings in object files generated by MSVC. llvm-svn: 222564
2014-11-22 03:57:25 +08:00
if (SL->isWide())
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
Mangler.getStream() << '1';
else
MS ABI: Mangle char16_t and char32_t string literals We previously had support for char and wchar_t string literals. VS 2015 added support for char16_t and char32_t. String literals must be mangled in the MS ABI in order for them to be deduplicated across translation units: their linker has no notion of mergeable section. Instead, they use the mangled name to make a COMDAT for the string literal; the COMDAT will merge with other COMDATs in other object files. This allows strings in object files generated by clang to get merged with strings in object files generated by MSVC. llvm-svn: 222564
2014-11-22 03:57:25 +08:00
Mangler.getStream() << '0';
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
// <literal-length>: The next part of the mangled name consists of the length
// of the string.
// The StringLiteral does not consider the NUL terminator byte(s) but the
// mangling does.
// N.B. The length is in terms of bytes, not characters.
Mangler.mangleNumber(SL->getByteLength() + SL->getCharByteWidth());
MS ABI: mangleStringLiteral shouldn't rely on the host's endianness No test case is needed, the one in-tree is sufficient. The build-bot never emailed me because something else had upset it. llvm-svn: 205225
2014-04-01 01:18:53 +08:00
auto GetLittleEndianByte = [&Mangler, &SL](unsigned Index) {
unsigned CharByteWidth = SL->getCharByteWidth();
uint32_t CodeUnit = SL->getCodeUnit(Index / CharByteWidth);
MS ABI: Simplify endian swapping code No functionality change. llvm-svn: 205250
2014-04-01 05:46:05 +08:00
unsigned OffsetInCodeUnit = Index % CharByteWidth;
return static_cast<char>((CodeUnit >> (8 * OffsetInCodeUnit)) & 0xff);
MS ABI: mangleStringLiteral shouldn't rely on the host's endianness No test case is needed, the one in-tree is sufficient. The build-bot never emailed me because something else had upset it. llvm-svn: 205225
2014-04-01 01:18:53 +08:00
};
auto GetBigEndianByte = [&Mangler, &SL](unsigned Index) {
unsigned CharByteWidth = SL->getCharByteWidth();
uint32_t CodeUnit = SL->getCodeUnit(Index / CharByteWidth);
MS ABI: Simplify endian swapping code No functionality change. llvm-svn: 205250
2014-04-01 05:46:05 +08:00
unsigned OffsetInCodeUnit = (CharByteWidth - 1) - (Index % CharByteWidth);
return static_cast<char>((CodeUnit >> (8 * OffsetInCodeUnit)) & 0xff);
MS ABI: mangleStringLiteral shouldn't rely on the host's endianness No test case is needed, the one in-tree is sufficient. The build-bot never emailed me because something else had upset it. llvm-svn: 205225
2014-04-01 01:18:53 +08:00
};
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
// CRC all the bytes of the StringLiteral.
[MS ABI] Switch to the CRC implementation in LLVM We now have an implementation of the CRC in LLVM's libSupport. Let's consolidate around that one. llvm-svn: 246591
2015-09-02 05:24:07 +08:00
llvm::JamCRC JC;
MS ABI: mangleStringLiteral shouldn't rely on the host's endianness No test case is needed, the one in-tree is sufficient. The build-bot never emailed me because something else had upset it. llvm-svn: 205225
2014-04-01 01:18:53 +08:00
for (unsigned I = 0, E = SL->getByteLength(); I != E; ++I)
[MS ABI] Switch to the CRC implementation in LLVM We now have an implementation of the CRC in LLVM's libSupport. Let's consolidate around that one. llvm-svn: 246591
2015-09-02 05:24:07 +08:00
JC.update(GetLittleEndianByte(I));
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
// The NUL terminator byte(s) were not present earlier,
// we need to manually process those bytes into the CRC.
for (unsigned NullTerminator = 0; NullTerminator < SL->getCharByteWidth();
++NullTerminator)
[MS ABI] Switch to the CRC implementation in LLVM We now have an implementation of the CRC in LLVM's libSupport. Let's consolidate around that one. llvm-svn: 246591
2015-09-02 05:24:07 +08:00
JC.update('\x00');
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
// <encoded-crc>: The CRC is encoded utilizing the standard number mangling
// scheme.
[MS ABI] Switch to the CRC implementation in LLVM We now have an implementation of the CRC in LLVM's libSupport. Let's consolidate around that one. llvm-svn: 246591
2015-09-02 05:24:07 +08:00
Mangler.mangleNumber(JC.getCRC());
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
MS ABI: Correct typo in mangleStringLiteral No functionality change. llvm-svn: 205156
2014-03-31 00:38:02 +08:00
// <encoded-string>: The mangled name also contains the first 32 _characters_
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
// (including null-terminator bytes) of the StringLiteral.
// Each character is encoded by splitting them into bytes and then encoding
// the constituent bytes.
auto MangleByte = [&Mangler](char Byte) {
// There are five different manglings for characters:
// - [a-zA-Z0-9_$]: A one-to-one mapping.
// - ?[a-z]: The range from \xe1 to \xfa.
// - ?[A-Z]: The range from \xc1 to \xda.
// - ?[0-9]: The set of [,/\:. \n\t'-].
// - ?$XX: A fallback which maps nibbles.
MS ABI: Simplify MangleByte further It turns out that the ranges where the '?' <letter> manglings occur are identical to the ranges of ASCII characters OR'd with 0x80. Thanks to Richard Smith for the insight! No functional change. llvm-svn: 205270
2014-04-01 08:05:57 +08:00
if (isIdentifierBody(Byte, /*AllowDollar=*/true)) {
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
Mangler.getStream() << Byte;
MS ABI: Simplify MangleByte further It turns out that the ranges where the '?' <letter> manglings occur are identical to the ranges of ASCII characters OR'd with 0x80. Thanks to Richard Smith for the insight! No functional change. llvm-svn: 205270
2014-04-01 08:05:57 +08:00
} else if (isLetter(Byte & 0x7f)) {
Mangler.getStream() << '?' << static_cast<char>(Byte & 0x7f);
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
} else {
MS ABI: Make the string mangling code more concise No functional change intended. llvm-svn: 224696
2014-12-22 14:24:49 +08:00
const char SpecialChars[] = {',', '/', '\\', ':', '.',
' ', '\n', '\t', '\'', '-'};
const char *Pos =
std::find(std::begin(SpecialChars), std::end(SpecialChars), Byte);
if (Pos != std::end(SpecialChars)) {
Mangler.getStream() << '?' << (Pos - std::begin(SpecialChars));
} else {
Mangler.getStream() << "?$";
Mangler.getStream() << static_cast<char>('A' + ((Byte >> 4) & 0xf));
Mangler.getStream() << static_cast<char>('A' + (Byte & 0xf));
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
}
}
};
// Enforce our 32 character max.
unsigned NumCharsToMangle = std::min(32U, SL->getLength());
MS ABI: mangleStringLiteral shouldn't rely on the host's endianness No test case is needed, the one in-tree is sufficient. The build-bot never emailed me because something else had upset it. llvm-svn: 205225
2014-04-01 01:18:53 +08:00
for (unsigned I = 0, E = NumCharsToMangle * SL->getCharByteWidth(); I != E;
++I)
MS ABI: Mangle char16_t and char32_t string literals We previously had support for char and wchar_t string literals. VS 2015 added support for char16_t and char32_t. String literals must be mangled in the MS ABI in order for them to be deduplicated across translation units: their linker has no notion of mergeable section. Instead, they use the mangled name to make a COMDAT for the string literal; the COMDAT will merge with other COMDATs in other object files. This allows strings in object files generated by clang to get merged with strings in object files generated by MSVC. llvm-svn: 222564
2014-11-22 03:57:25 +08:00
if (SL->isWide())
MangleByte(GetBigEndianByte(I));
else
MangleByte(GetLittleEndianByte(I));
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
// Encode the NUL terminator if there is room.
if (NumCharsToMangle < 32)
MS ABI: mangleStringLiteral shouldn't rely on the host's endianness No test case is needed, the one in-tree is sufficient. The build-bot never emailed me because something else had upset it. llvm-svn: 205225
2014-04-01 01:18:53 +08:00
for (unsigned NullTerminator = 0; NullTerminator < SL->getCharByteWidth();
++NullTerminator)
MangleByte(0);
MS ABI: Eliminate Duplicate Strings COFF doesn't have mergeable sections so LLVM/clang's normal tactics for string deduplication will not have any effect. To remedy this we place each string inside it's own section and mark the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the string has an external name that we can generate from it's contents. To be compatible with MSVC, we must use their scheme. Otherwise identical strings in translation units from clang may not be deduplicated with translation units in MSVC. This fixes PR18248. N.B. We will not attempt to do anything with a string literal which is not of type 'char' or 'wchar_t' because their compiler does not support unicode string literals as of this date. Further, we avoid doing this if either -fwritable-strings or -fsanitize=address are present. This reverts commit r204596. llvm-svn: 204675
2014-03-25 05:43:36 +08:00
Mangler.getStream() << '@';
}
Extract ABI-specific parts of MangleContext into separate classes Reviewed at http://llvm-reviews.chandlerc.com/D1807 llvm-svn: 191878
2013-10-03 14:26:13 +08:00
MicrosoftMangleContext *
MicrosoftMangleContext::create(ASTContext &Context, DiagnosticsEngine &Diags) {
return new MicrosoftMangleContextImpl(Context, Diags);
Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style. llvm-svn: 170431
2012-12-18 22:30:41 +08:00
}