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

3494 lines
130 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 ---------===//
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
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 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"
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
#include "clang/AST/DeclOpenMP.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/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] 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] Mangle a hash of the main file path into anonymous namespaces Summary: This is needed to avoid conflicts in mangled names for codeview types in anonymous namespaces. In CodeView, types refer to each other typically through forward declarations, which contain mangled names. These names have to be unique, otherwise the debugger will look up the mangled name and find the wrong definition. Furthermore, ThinLTO will deduplicate the types, and debug info verification can fail when the types have the wrong sizes. This is PR38608. Fixes PR38609. Reviewers: majnemer, inglorion, hans Subscribers: mehdi_amini, aprantl, JDevlieghere, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50877 llvm-svn: 340079
2018-08-18 04:59:27 +08:00
#include "llvm/Support/xxhash.h"
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
#include "llvm/Support/MD5.h"
#include "llvm/Support/MathExtras.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 {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
struct msvc_hashing_ostream : public llvm::raw_svector_ostream {
raw_ostream &OS;
llvm::SmallString<64> Buffer;
msvc_hashing_ostream(raw_ostream &OS)
: llvm::raw_svector_ostream(Buffer), OS(OS) {}
~msvc_hashing_ostream() override {
StringRef MangledName = str();
bool StartsWithEscape = MangledName.startswith("\01");
if (StartsWithEscape)
MangledName = MangledName.drop_front(1);
if (MangledName.size() <= 4096) {
OS << str();
return;
}
llvm::MD5 Hasher;
llvm::MD5::MD5Result Hash;
Hasher.update(MangledName);
Hasher.final(Hash);
SmallString<32> HexString;
llvm::MD5::stringifyResult(Hash, HexString);
if (StartsWithEscape)
OS << '\01';
OS << "??@" << HexString << '@';
}
};
[MS ABI] Implement more of the Itanium mangling rules We didn't implement handle corner cases like: - lambdas used to initialize a field - lambdas in default argument initializers This fixes PR31197. Differential Revision: https://reviews.llvm.org/D27226 llvm-svn: 288826
2016-12-07 01:01:02 +08:00
static const DeclContext *
getLambdaDefaultArgumentDeclContext(const Decl *D) {
if (const auto *RD = dyn_cast<CXXRecordDecl>(D))
if (RD->isLambda())
if (const auto *Parm =
dyn_cast_or_null<ParmVarDecl>(RD->getLambdaContextDecl()))
return Parm->getDeclContext();
return nullptr;
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Retrieve the declaration context that should be used when mangling
[-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
/// 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.
[MS ABI] Implement more of the Itanium mangling rules We didn't implement handle corner cases like: - lambdas used to initialize a field - lambdas in default argument initializers This fixes PR31197. Differential Revision: https://reviews.llvm.org/D27226 llvm-svn: 288826
2016-12-07 01:01:02 +08:00
if (const auto *LDADC = getLambdaDefaultArgumentDeclContext(D))
return LDADC;
[-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
// 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();
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
if (isa<CapturedDecl>(DC) || isa<OMPDeclareReductionDecl>(DC) ||
isa<OMPDeclareMapperDecl>(DC)) {
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
return getEffectiveDeclContext(cast<Decl>(DC));
}
[-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
[MS ABI] Ignore transparent contexts when determining the effective context We didn't skip over extern "C++" contexts, causing us to mangle things which don't need to be mangled. llvm-svn: 270089
2016-05-20 02:15:53 +08:00
return DC->getRedeclContext();
[-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
}
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))
[MS] Fix function type mangling of default ctor closures Use the canonical decl in pointer comparisons with the default constructor closure decl. Otherwise we don't produce the correct "@@QAEXXZ" mangling, which essentially means "void(void) thiscall public instance method". llvm-svn: 291448
2017-01-10 01:04:37 +08:00
return FTD->getTemplatedDecl()->getCanonicalDecl();
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())
[MS] Fix function type mangling of default ctor closures Use the canonical decl in pointer comparisons with the default constructor closure decl. Otherwise we don't produce the correct "@@QAEXXZ" mangling, which essentially means "void(void) thiscall public instance method". llvm-svn: 291448
2017-01-10 01:04:37 +08:00
return FTD->getTemplatedDecl()->getCanonicalDecl();
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
[MS] Fix function type mangling of default ctor closures Use the canonical decl in pointer comparisons with the default constructor closure decl. Otherwise we don't produce the correct "@@QAEXXZ" mangling, which essentially means "void(void) thiscall public instance method". llvm-svn: 291448
2017-01-10 01:04:37 +08:00
return FD->getCanonicalDecl();
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
/// 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;
[MS] Mangle a hash of the main file path into anonymous namespaces Summary: This is needed to avoid conflicts in mangled names for codeview types in anonymous namespaces. In CodeView, types refer to each other typically through forward declarations, which contain mangled names. These names have to be unique, otherwise the debugger will look up the mangled name and find the wrong definition. Furthermore, ThinLTO will deduplicate the types, and debug info verification can fail when the types have the wrong sizes. This is PR38608. Fixes PR38609. Reviewers: majnemer, inglorion, hans Subscribers: mehdi_amini, aprantl, JDevlieghere, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50877 llvm-svn: 340079
2018-08-18 04:59:27 +08:00
SmallString<16> AnonymousNamespaceHash;
[-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:
[MS] Mangle a hash of the main file path into anonymous namespaces Summary: This is needed to avoid conflicts in mangled names for codeview types in anonymous namespaces. In CodeView, types refer to each other typically through forward declarations, which contain mangled names. These names have to be unique, otherwise the debugger will look up the mangled name and find the wrong definition. Furthermore, ThinLTO will deduplicate the types, and debug info verification can fail when the types have the wrong sizes. This is PR38608. Fixes PR38609. Reviewers: majnemer, inglorion, hans Subscribers: mehdi_amini, aprantl, JDevlieghere, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50877 llvm-svn: 340079
2018-08-18 04:59:27 +08:00
MicrosoftMangleContextImpl(ASTContext &Context, DiagnosticsEngine &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,
Fix some DenseMap use-after-rehash bugs and hoist MethodVFTableLocation This re-lands r328845 with fixes for crbug.com/827810. The initial motiviation was to hoist MethodVFTableLocation to global scope so it could be forward declared. In this patch, I noticed that MicrosoftVTableContext uses some risky patterns. It has methods that return references to data stored in DenseMaps. I've made some of them return by value for trivial structs and I've moved some things into separate allocations. llvm-svn: 329007
2018-04-03 04:00:39 +08:00
const MethodVFTableLocation &ML,
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 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,
[MS ABI] Support throwing/catching __unaligned types We need to mark the appropriate bits in ThrowInfo and HandlerType so that the personality routine can correctly handle qualification conversions. llvm-svn: 275154
2016-07-12 12:42:50 +08:00
bool IsUnaligned, uint32_t NumEntries,
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 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: 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) {
const DeclContext *DC = getEffectiveDeclContext(ND);
if (!DC->isFunctionOrMethod())
return false;
[MS ABI] Don't crash while mangling recursive lambdas We might get into bad situations where we try to embed the signature of an inner lambda into an outer lambda which cannot work: the inner lambda wants to embed the name of the outer lambda! Instead, omit the return type for lambdas. This fixes PR26105. N.B. While we are here, make lambdas nested within functions use an artificial scope so that they can get demangled. llvm-svn: 258003
2016-01-17 15:09:24 +08:00
// Lambda closure types are already numbered, give out a phony number so
// that they demangle nicely.
[MS ABI] Implement more of the Itanium mangling rules We didn't implement handle corner cases like: - lambdas used to initialize a field - lambdas in default argument initializers This fixes PR31197. Differential Revision: https://reviews.llvm.org/D27226 llvm-svn: 288826
2016-12-07 01:01:02 +08:00
if (const auto *RD = dyn_cast<CXXRecordDecl>(ND)) {
if (RD->isLambda()) {
disc = 1;
return true;
}
[MS ABI] Don't crash while mangling recursive lambdas We might get into bad situations where we try to embed the signature of an inner lambda into an outer lambda which cannot work: the inner lambda wants to embed the name of the outer lambda! Instead, omit the return type for lambdas. This fixes PR26105. N.B. While we are here, make lambdas nested within functions use an artificial scope so that they can get demangled. llvm-svn: 258003
2016-01-17 15:09:24 +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
// 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;
}
[MS] Mangle a hash of the main file path into anonymous namespaces Summary: This is needed to avoid conflicts in mangled names for codeview types in anonymous namespaces. In CodeView, types refer to each other typically through forward declarations, which contain mangled names. These names have to be unique, otherwise the debugger will look up the mangled name and find the wrong definition. Furthermore, ThinLTO will deduplicate the types, and debug info verification can fail when the types have the wrong sizes. This is PR38608. Fixes PR38609. Reviewers: majnemer, inglorion, hans Subscribers: mehdi_amini, aprantl, JDevlieghere, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50877 llvm-svn: 340079
2018-08-18 04:59:27 +08:00
/// Return a character sequence that is (somewhat) unique to the TU suitable
/// for mangling anonymous namespaces.
StringRef getAnonymousNamespaceHash() const {
return AnonymousNamespaceHash;
}
[-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:
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
void mangleInitFiniStub(const VarDecl *D, char CharCode, 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
};
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] Change the ArgBackRefMap to hold const qualified pointers Just a cleanup, no functional change is intended. llvm-svn: 256663
2015-12-31 13:36:52 +08:00
typedef llvm::DenseMap<const 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;
Add a spelling of pass_object_size that uses __builtin_dynamic_object_size The attribute pass_dynamic_object_size(n) behaves exactly like pass_object_size(n), but instead of evaluating __builtin_object_size on calls, it evaluates __builtin_dynamic_object_size, which has the potential to produce runtime code when the object size can't be determined statically. Differential revision: https://reviews.llvm.org/D58757 llvm-svn: 356515
2019-03-20 04:44:18 +08:00
typedef std::set<std::pair<int, bool>> PassObjectSizeArgsSet;
[MS ABI] Improve our mangling of pass_object_size We didn't add the artificial pass_object_size arguments to the backreference map which bloated the size of manglings which involved pass_object_size with duplicate types. This lets us go from: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@0W4__pass_object_size1@3@@Z to: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@01@Z llvm-svn: 256622
2015-12-30 13:13:03 +08:00
PassObjectSizeArgsSet PassObjectSizeArgs;
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
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; }
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
void 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
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);
Fix some DenseMap use-after-rehash bugs and hoist MethodVFTableLocation This re-lands r328845 with fixes for crbug.com/827810. The initial motiviation was to hoist MethodVFTableLocation to global scope so it could be forward declared. In this patch, I noticed that MicrosoftVTableContext uses some risky patterns. It has methods that return references to data stored in DenseMaps. I've made some of them return by value for trivial structs and I've moved some things into separate allocations. llvm-svn: 329007
2018-04-03 04:00:39 +08:00
void mangleVirtualMemPtrThunk(const CXXMethodDecl *MD,
const 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 ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
void mangleTagTypeKind(TagTypeKind TK);
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
void mangleArtificialTagType(TagTypeKind TK, StringRef UnqualifiedName,
[MS ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
ArrayRef<StringRef> NestedNames = None);
Add AddressSpace mangling to MS mode All of the symbols demangle on llvm-undname and demangler.com. This address space qualifier is useful for when we want to use opencl C++ in Windows mode. Additionally, C++ address-space using functions will now be usable on windows. Differential Revision: https://reviews.llvm.org/D55715 Change-Id: Ife4506613c3cce778a783456d62117fbf7d83c26 llvm-svn: 349209
2018-12-15 07:17:34 +08:00
void mangleAddressSpaceType(QualType T, Qualifiers Quals, 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
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,
Update Microsoft name mangling scheme for exception specifiers in the type system Summary: The msvc exception specifier for noexcept function types has changed from the prior default of "Z" to "_E" if the function cannot throw when compiling with /std:C++17. Patch by Zachary Henkel! Reviewers: zturner, rnk Reviewed By: rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55685 llvm-svn: 349414
2018-12-18 07:10:43 +08:00
bool ForceThisQuals = false,
bool MangleExceptionSpec = true);
[-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:
[MS] Fix function type mangling of default ctor closures Use the canonical decl in pointer comparisons with the default constructor closure decl. Otherwise we don't produce the correct "@@QAEXXZ" mangling, which essentially means "void(void) thiscall public instance method". llvm-svn: 291448
2017-01-10 01:04:37 +08:00
bool isStructorDecl(const NamedDecl *ND) const {
return ND == Structor || getStructor(ND) == Structor;
}
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 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);
[MS ABI] Improve our mangling of pass_object_size We didn't add the artificial pass_object_size arguments to the backreference map which bloated the size of manglings which involved pass_object_size with duplicate types. This lets us go from: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@0W4__pass_object_size1@3@@Z to: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@01@Z llvm-svn: 256622
2015-12-30 13:13:03 +08:00
void manglePassObjectSizeArg(const PassObjectSizeAttr *POSA);
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] Fix mangling of vector types in QMM_Result contexts. If QMM_Result is set (which it is for return types, RTTI descriptors, and exception type descriptors), tag types (structs, enums, classes, unions) get their qualifiers mangled in. __m64 and friends is a struct/union thingy in MSVC, but not in clang's headers. To make mangling work, we call mangleArtificalTagType(TTK_Union/TTK_Struct for the vector types to mangle them as tag types -- but the isa<TagType> check when mangling in QMM_Result mode isn't true for these vector types. Add an isArtificialTagType() function and check for that too. Fixes PR37276 and some other issues. I tried to audit all references to TagDecl and TagType in MicrosoftMangle.cpp to find other places where we need to call mangleArtificalTagType(), but couldn't find any. I tried to audit all calls to mangleArtificalTagType() to see if isArtificialTagType() needs to handle more than just the vector types, but as far as I can tell all other types we use it for are types that MSVC can't handle at all (Objective-C types etc). https://reviews.llvm.org/D49597 llvm-svn: 337732
2018-07-24 04:04:00 +08:00
bool isArtificialTagType(QualType T) const;
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
// 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);
AST: support ObjC lifetime qualifiers in MS ABI Adjust the ObjC protocol conformance workaround to be more extensible. Use a synthetic type for the protocol (`struct Protocol`). Embed this within a reserved namespace to permit extending the extended pointer type qualifiers similarly for ObjC lifetime qualifiers. Introduce additional special handling for `__autoreleasing`, `__strong`, and `__weak` Objective C lifetime qualifiers. We decorate these by creating an artificial template type `Autoreleasing`, `Strong`, or `Weak` in the `__ObjC` namespace. These are only considered in the template type specialization and not the function parameter. llvm-svn: 324701
2018-02-09 11:23:54 +08:00
void mangleObjCProtocol(const ObjCProtocolDecl *PD);
void mangleObjCLifetime(const QualType T, Qualifiers Quals,
SourceRange Range);
AST: add missing ObjC extensions to MS style name decoration Add support for encoding type arguments for lightweight generics in Objective-C++ mode. Additionally, add support for the `__kindof` modifier. This should complete the coverage of the ObjC extensions that clang currently supports under the MS style name decoration scheme. This is implemented similar to the Objective-C lifetime qualifiers decoration: a template specialization in the `__ObjC` namespace so that we can interoperate with Microsoft's tools as well as ensure that we do not accidentally collide with new features in the Microsoft implementation. Since the `__kindof` appertains to the type and not the pointer, we apply the template specialization to the underlying type instead of the pointer type. Unfortunately, until D52581 is resolved, the generated name is not really compatible with the MS tools as well as breaks interoperability with Objective-C++ and C++. This resolves PR37754! llvm-svn: 343338
2018-09-29 00:47:53 +08:00
void mangleObjCKindOfType(const ObjCObjectType *T, Qualifiers Quals,
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
};
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
[MS] Mangle a hash of the main file path into anonymous namespaces Summary: This is needed to avoid conflicts in mangled names for codeview types in anonymous namespaces. In CodeView, types refer to each other typically through forward declarations, which contain mangled names. These names have to be unique, otherwise the debugger will look up the mangled name and find the wrong definition. Furthermore, ThinLTO will deduplicate the types, and debug info verification can fail when the types have the wrong sizes. This is PR38608. Fixes PR38609. Reviewers: majnemer, inglorion, hans Subscribers: mehdi_amini, aprantl, JDevlieghere, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50877 llvm-svn: 340079
2018-08-18 04:59:27 +08:00
MicrosoftMangleContextImpl::MicrosoftMangleContextImpl(ASTContext &Context,
DiagnosticsEngine &Diags)
: MicrosoftMangleContext(Context, Diags) {
// To mangle anonymous namespaces, hash the path to the main source file. The
// path should be whatever (probably relative) path was passed on the command
// line. The goal is for the compiler to produce the same output regardless of
// working directory, so use the uncanonicalized relative path.
//
// It's important to make the mangled names unique because, when CodeView
// debug info is in use, the debugger uses mangled type names to distinguish
// between otherwise identically named types in anonymous namespaces.
//
// These symbols are always internal, so there is no need for the hash to
// match what MSVC produces. For the same reason, clang is free to change the
// hash at any time without breaking compatibility with old versions of clang.
// The generated names are intended to look similar to what MSVC generates,
// which are something like "?A0x01234567@".
SourceManager &SM = Context.getSourceManager();
if (const FileEntry *FE = SM.getFileEntryForID(SM.getMainFileID())) {
// Truncate the hash so we get 8 characters of hexadecimal.
uint32_t TruncatedHash = uint32_t(xxHash64(FE->getName()));
AnonymousNamespaceHash = llvm::utohexstr(TruncatedHash);
} else {
// If we don't have a path to the main file, we'll just use 0.
AnonymousNamespaceHash = "0";
}
}
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;
P0217R3: code generation support for decomposition declarations. llvm-svn: 278642
2016-08-15 09:33:41 +08:00
const VarDecl *VD = dyn_cast<VarDecl>(D);
if (VD && !isa<DecompositionDecl>(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
// 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 &&
[MS ABI] Mangle static anonymous unions We believed that internal linkage variables at global scope which are not variable template specializations did not have to be mangled. However, static anonymous unions have no identifier and therefore must be mangled. This fixes PR18204. llvm-svn: 250997
2015-10-22 15:15:56 +08:00
!isa<VarTemplateSpecializationDecl>(D) &&
D->getIdentifier() != nullptr)
[-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;
}
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);
[AST] Revert mangling changes from r339428 As discussed in https://reviews.llvm.org/D50144, we want Obj-C classes to have the same mangling as C++ structs, to support headers like the following: ``` @class I; struct I; void f(I *); ``` since the header can be used from both C++ and Obj-C++ TUs, and we want a consistent mangling across the two to prevent link errors. Itanium mangles both the same way, and so should the MS ABI. The main concern with having the same mangling for C++ structs and Obj-C classes was that we want to treat them differently for the purposes of exception handling, e.g. we don't want a C++ catch statement for a struct to be able to catch an Obj-C class with the same name as the struct. We can accomplish this by mangling Obj-C class names differently in their RTTI, which I'll do in a follow-up patch. Differential Revision: https://reviews.llvm.org/D52581 llvm-svn: 343808
2018-10-05 03:50:14 +08:00
else
[MS ABI] Mark an unreachable path appropriately No functional change is intended, just a small cleanup. llvm-svn: 256582
2015-12-30 06:02:10 +08:00
llvm_unreachable("Tried to mangle unexpected NamedDecl!");
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
Fix funciton->function typo. llvm-svn: 255840
2015-12-17 07:10:46 +08:00
// other words, when it is an overloaded extern "C" function).
[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
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
Update Microsoft name mangling scheme for exception specifiers in the type system Summary: The msvc exception specifier for noexcept function types has changed from the prior default of "Z" to "_E" if the function cannot throw when compiling with /std:C++17. Patch by Zachary Henkel! Reviewers: zturner, rnk Reviewed By: rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55685 llvm-svn: 349414
2018-12-18 07:10:43 +08:00
mangleFunctionType(FT, FD, false, false);
[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());
Fix some DenseMap use-after-rehash bugs and hoist MethodVFTableLocation This re-lands r328845 with fixes for crbug.com/827810. The initial motiviation was to hoist MethodVFTableLocation to global scope so it could be forward declared. In this patch, I noticed that MicrosoftVTableContext uses some risky patterns. It has methods that return references to data stored in DenseMaps. I've made some of them return by value for trivial structs and I've moved some things into separate allocations. llvm-svn: 329007
2018-04-03 04:00:39 +08:00
MethodVFTableLocation ML =
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
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(
Fix some DenseMap use-after-rehash bugs and hoist MethodVFTableLocation This re-lands r328845 with fixes for crbug.com/827810. The initial motiviation was to hoist MethodVFTableLocation to global scope so it could be forward declared. In this patch, I noticed that MicrosoftVTableContext uses some risky patterns. It has methods that return references to data stored in DenseMaps. I've made some of them return by value for trivial structs and I've moved some things into separate allocations. llvm-svn: 329007
2018-04-03 04:00:39 +08:00
const CXXMethodDecl *MD, const MethodVFTableLocation &ML) {
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
// 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.
[MS ABI] Add variable templates to the NameBackReferences Only function template specializations are exempt from being added to the NameBackReferences. Redundant variable template specializations should be appropriately substituted. llvm-svn: 256623
2015-12-30 13:40:32 +08:00
if (isa<FunctionTemplateDecl>(TD)) {
[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
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
Remove trailing space sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-31 03:24:48 +08:00
// a namespace suffix) to a string using the extra mangler and then use
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
// 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()) {
[MS] Mangle a hash of the main file path into anonymous namespaces Summary: This is needed to avoid conflicts in mangled names for codeview types in anonymous namespaces. In CodeView, types refer to each other typically through forward declarations, which contain mangled names. These names have to be unique, otherwise the debugger will look up the mangled name and find the wrong definition. Furthermore, ThinLTO will deduplicate the types, and debug info verification can fail when the types have the wrong sizes. This is PR38608. Fixes PR38609. Reviewers: majnemer, inglorion, hans Subscribers: mehdi_amini, aprantl, JDevlieghere, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50877 llvm-svn: 340079
2018-08-18 04:59:27 +08:00
Out << "?A0x" << Context.getAnonymousNamespaceHash() << '@';
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
P0217R3: code generation support for decomposition declarations. llvm-svn: 278642
2016-08-15 09:33:41 +08:00
if (const DecompositionDecl *DD = dyn_cast<DecompositionDecl>(ND)) {
// FIXME: Invented mangling for decomposition declarations:
// [X,Y,Z]
// where X,Y,Z are the names of the bindings.
llvm::SmallString<128> Name("[");
for (auto *BD : DD->bindings()) {
if (Name.size() > 1)
Name += ',';
Name += BD->getDeclName().getAsIdentifierInfo()->getName();
}
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
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_");
[MS ABI] Implement more of the Itanium mangling rules We didn't implement handle corner cases like: - lambdas used to initialize a field - lambdas in default argument initializers This fixes PR31197. Differential Revision: https://reviews.llvm.org/D27226 llvm-svn: 288826
2016-12-07 01:01:02 +08:00
Decl *LambdaContextDecl = Record->getLambdaContextDecl();
unsigned LambdaManglingNumber = Record->getLambdaManglingNumber();
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 LambdaId;
[MS ABI] Implement more of the Itanium mangling rules We didn't implement handle corner cases like: - lambdas used to initialize a field - lambdas in default argument initializers This fixes PR31197. Differential Revision: https://reviews.llvm.org/D27226 llvm-svn: 288826
2016-12-07 01:01:02 +08:00
const ParmVarDecl *Parm =
dyn_cast_or_null<ParmVarDecl>(LambdaContextDecl);
const FunctionDecl *Func =
Parm ? dyn_cast<FunctionDecl>(Parm->getDeclContext()) : nullptr;
if (Func) {
unsigned DefaultArgNo =
Func->getNumParams() - Parm->getFunctionScopeIndex();
Name += llvm::utostr(DefaultArgNo);
Name += "_";
}
if (LambdaManglingNumber)
LambdaId = LambdaManglingNumber;
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
else
LambdaId = Context.getLambdaId(Record);
Name += llvm::utostr(LambdaId);
Name += ">";
mangleSourceName(Name);
[MS ABI] Implement more of the Itanium mangling rules We didn't implement handle corner cases like: - lambdas used to initialize a field - lambdas in default argument initializers This fixes PR31197. Differential Revision: https://reviews.llvm.org/D27226 llvm-svn: 288826
2016-12-07 01:01:02 +08:00
// If the context of a closure type is an initializer for a class
// member (static or nonstatic), it is encoded in a qualified name.
if (LambdaManglingNumber && LambdaContextDecl) {
if ((isa<VarDecl>(LambdaContextDecl) ||
isa<FieldDecl>(LambdaContextDecl)) &&
LambdaContextDecl->getDeclContext()->isRecord()) {
mangleUnqualifiedName(cast<NamedDecl>(LambdaContextDecl));
}
}
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
break;
}
}
[MS ABI] Mangle unnamed enums correctly Unnamed enums take the name of the first enumerator they define. llvm-svn: 290509
2016-12-25 13:26:02 +08:00
llvm::SmallString<64> Name;
[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] Mangle unnamed enums correctly Unnamed enums take the name of the first enumerator they define. llvm-svn: 290509
2016-12-25 13:26:02 +08:00
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
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.
[MS ABI] Mangle unnamed enums correctly Unnamed enums take the name of the first enumerator they define. llvm-svn: 290509
2016-12-25 13:26:02 +08:00
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
Name += TND->getName();
[MS ABI] Mangle unnamed empty enums (PR37723) Differential Revision: https://reviews.llvm.org/D47875 llvm-svn: 334388
2018-06-11 14:54:23 +08:00
} else if (isa<EnumDecl>(TD) &&
cast<EnumDecl>(TD)->enumerator_begin() !=
cast<EnumDecl>(TD)->enumerator_end()) {
// Anonymous non-empty enums mangle in the first enumerator.
auto *ED = cast<EnumDecl>(TD);
[MS ABI] Mangle unnamed enums correctly Unnamed enums take the name of the first enumerator they define. llvm-svn: 290509
2016-12-25 13:26:02 +08:00
Name += "<unnamed-enum-";
[MS ABI] Mangle unnamed empty enums (PR37723) Differential Revision: https://reviews.llvm.org/D47875 llvm-svn: 334388
2018-06-11 14:54:23 +08:00
Name += ED->enumerator_begin()->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.
[MS ABI] Mangle unnamed enums correctly Unnamed enums take the name of the first enumerator they define. llvm-svn: 290509
2016-12-25 13:26:02 +08:00
Name += "<unnamed-type-$S";
[MS ABI] Mangle static anonymous unions We believed that internal linkage variables at global scope which are not variable template specializations did not have to be mangled. However, static anonymous unions have no identifier and therefore must be mangled. This fixes PR18204. llvm-svn: 250997
2015-10-22 15:15:56 +08:00
Name += llvm::utostr(Context.getAnonymousStructId(TD) + 1);
[-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:
Add a stub mangling for ObjC selectors in the Microsoft ABI. This mangling is used only for outlined SEH finally blocks, which have internal linkage. This fixes the failure of CodeGenObjC/2007-04-03-ObjcEH.m on builds with expensive checks enabled, on Windows. This test should probably be specifying a triple: it currently picks up whatever the host environment is using. Unfortunately, I have no idea what it is trying to test, because it contains no comments and predates Clang having working Objective-C IR generation. llvm-svn: 339667
2018-08-14 18:04:36 +08:00
case DeclarationName::ObjCMultiArgSelector: {
// This is reachable only when constructing an outlined SEH finally
// block. Nothing depends on this mangling and it's used only with
// functinos with internal linkage.
llvm::SmallString<64> Name;
mangleSourceName(Name.str());
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::CXXConstructorName:
Follow up to r291448: use isStructorDecl in one more place This pointer comparison has shown to be error-prone, so use the standard helper for it. NFC llvm-svn: 291450
2017-01-10 01:09:59 +08:00
if (isStructorDecl(ND)) {
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 (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:
[MS] Fix function type mangling of default ctor closures Use the canonical decl in pointer comparisons with the default constructor closure decl. Otherwise we don't produce the correct "@@QAEXXZ" mangling, which essentially means "void(void) thiscall public instance method". llvm-svn: 291448
2017-01-10 01:04:37 +08:00
if (isStructorDecl(ND))
Emit virtual/deleting destructors properly with -cxx-abi microsoft, PR15058 llvm-svn: 175045
2013-02-13 16:37:51 +08:00
// 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
P0091R3: Implement basic parsing support for C++17 deduction-guides. We model deduction-guides as functions with a new kind of name that identifies the template whose deduction they guide; the bulk of this patch is adding the new name kind. This gives us a clean way to attach an extensible list of guides to a class template in a way that doesn't require any special handling in AST files etc (and we're going to need these functions we come to performing deduction). llvm-svn: 294266
2017-02-07 09:37:30 +08:00
case DeclarationName::CXXDeductionGuideName:
llvm_unreachable("Can't mangle a deduction guide 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
case DeclarationName::CXXUsingDirective:
llvm_unreachable("Can't mangle a using directive name!");
}
}
AST: support SwiftCC on MS ABI Microsoft has reserved the identifier 'S' as the swift calling convention. Decorate the symbols appropriately. This enables swift on Windows. llvm-svn: 324439
2018-02-07 09:55:08 +08:00
// <postfix> ::= <unqualified-name> [<postfix>]
// ::= <substitution> [<postfix>]
[-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) {
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);
[-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)) {
AST: enhance mangling for blocks with MS ABI When generating the decorated name for a static variable inside a BlockDecl, construct a scope for the block invocation function that homes the parameter. This allows for arbitrary nesting of the blocks even if the variables are shadowed. Furthermore, using this for the name allows for undname to properly undecorated the name for us. It shows up as the synthetic __block_invocation function that the compiler emitted in the local scope. llvm-svn: 306347
2017-06-27 07:28:42 +08:00
auto Discriminate =
[](StringRef Name, const unsigned Discriminator,
const unsigned ParameterDiscriminator) -> std::string {
std::string Buffer;
llvm::raw_string_ostream Stream(Buffer);
Stream << Name;
if (Discriminator)
Stream << '_' << Discriminator;
if (ParameterDiscriminator)
Stream << '_' << ParameterDiscriminator;
return Stream.str();
};
unsigned Discriminator = BD->getBlockManglingNumber();
if (!Discriminator)
Discriminator = Context.getBlockId(BD, /*Local=*/false);
// Mangle the parameter position as a discriminator to deal with unnamed
// parameters. Rather than mangling the unqualified parameter name,
// always use the position to give a uniform mangling.
unsigned ParameterDiscriminator = 0;
if (const auto *MC = BD->getBlockManglingContextDecl())
if (const auto *P = dyn_cast<ParmVarDecl>(MC))
if (const auto *F = dyn_cast<FunctionDecl>(P->getDeclContext()))
ParameterDiscriminator =
F->getNumParams() - P->getFunctionScopeIndex();
DC = getEffectiveDeclContext(BD);
Out << '?';
mangleSourceName(Discriminate("_block_invoke", Discriminator,
ParameterDiscriminator));
// If we have a block mangling context, encode that now. This allows us
// to discriminate between named static data initializers in the same
// scope. This is handled differently from parameters, which use
// positions to discriminate between multiple instances.
if (const auto *MC = BD->getBlockManglingContextDecl())
if (!isa<ParmVarDecl>(MC))
if (const auto *ND = dyn_cast<NamedDecl>(MC))
mangleUnqualifiedName(ND);
// MS ABI and Itanium manglings are in inverted scopes. In the case of a
Fix typos in clang Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
2018-04-06 23:14:32 +08:00
// RecordDecl, mangle the entire scope hierarchy at this point rather than
AST: enhance mangling for blocks with MS ABI When generating the decorated name for a static variable inside a BlockDecl, construct a scope for the block invocation function that homes the parameter. This allows for arbitrary nesting of the blocks even if the variables are shadowed. Furthermore, using this for the name allows for undname to properly undecorated the name for us. It shows up as the synthetic __block_invocation function that the compiler emitted in the local scope. llvm-svn: 306347
2017-06-27 07:28:42 +08:00
// just the unqualified name to get the ordering correct.
if (const auto *RD = dyn_cast<RecordDecl>(DC))
mangleName(RD);
else
Out << '@';
// void __cdecl
Out << "YAX";
// struct __block_literal *
Out << 'P';
// __ptr64
if (PointersAre64Bit)
Out << 'E';
Out << 'A';
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct,
AST: enhance mangling for blocks with MS ABI When generating the decorated name for a static variable inside a BlockDecl, construct a scope for the block invocation function that homes the parameter. This allows for arbitrary nesting of the blocks even if the variables are shadowed. Furthermore, using this for the name allows for undname to properly undecorated the name for us. It shows up as the synthetic __block_invocation function that the compiler emitted in the local scope. llvm-svn: 306347
2017-06-27 07:28:42 +08:00
Discriminate("__block_literal", Discriminator,
ParameterDiscriminator));
Out << "@Z";
// If the effective context was a Record, we have fully mangled the
// qualified name and do not need to continue.
if (isa<RecordDecl>(DC))
break;
continue;
[-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
} 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;
[MS ABI] Implement more of the Itanium mangling rules We didn't implement handle corner cases like: - lambdas used to initialize a field - lambdas in default argument initializers This fixes PR31197. Differential Revision: https://reviews.llvm.org/D27226 llvm-svn: 288826
2016-12-07 01:01:02 +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
mangleUnqualifiedName(ND);
[MS ABI] Implement more of the Itanium mangling rules We didn't implement handle corner cases like: - lambdas used to initialize a field - lambdas in default argument initializers This fixes PR31197. Differential Revision: https://reviews.llvm.org/D27226 llvm-svn: 288826
2016-12-07 01:01:02 +08:00
// Lambdas in default arguments conceptually belong to the function the
// parameter corresponds to.
if (const auto *LDADC = getLambdaDefaultArgumentDeclContext(ND)) {
DC = LDADC;
continue;
}
}
[-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
}
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;
[Coroutines] Add proper mangling for operator co_await for MicrosoftABI Reviewers: rnk, rsmith Subscribers: mehdi_amini, cfe-commits Differential Revision: https://reviews.llvm.org/D25045 llvm-svn: 282645
2016-09-29 06:37:17 +08:00
// <operator-name> ::= ?__L # co_await
case OO_Coawait: Out << "?__L"; break;
Revert r345330 "Add MS ABI mangling for operator<=>." The generated MS manglings differ between 32- and 64-bit, and the test only expects the latter. See also the commit email thread. > Thanks to Cameron DaCamara at Microsoft for letting us know what their > chosen mangling is here! llvm-svn: 345380
2018-10-26 21:05:45 +08:00
case OO_Spaceship: {
// FIXME: Once MS picks a mangling, use it.
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this three-way comparison operator yet");
Diags.Report(Loc, DiagID);
break;
}
[c++2a] P0515R3: Support for overloaded operator<=>. No CodeGen support for MSABI yet, we don't know how to mangle this there. llvm-svn: 319513
2017-12-01 10:13:10 +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;
[MS ABI] Improve our mangling of pass_object_size We didn't add the artificial pass_object_size arguments to the backreference map which bloated the size of manglings which involved pass_object_size with duplicate types. This lets us go from: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@0W4__pass_object_size1@3@@Z to: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@01@Z llvm-svn: 256622
2015-12-30 13:13:03 +08:00
PassObjectSizeArgsSet OuterPassObjectSizeArgs;
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);
[MS ABI] Improve our mangling of pass_object_size We didn't add the artificial pass_object_size arguments to the backreference map which bloated the size of manglings which involved pass_object_size with duplicate types. This lets us go from: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@0W4__pass_object_size1@3@@Z to: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@01@Z llvm-svn: 256622
2015-12-30 13:13:03 +08:00
PassObjectSizeArgs.swap(OuterPassObjectSizeArgs);
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
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);
[MS ABI] Improve our mangling of pass_object_size We didn't add the artificial pass_object_size arguments to the backreference map which bloated the size of manglings which involved pass_object_size with duplicate types. This lets us go from: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@0W4__pass_object_size1@3@@Z to: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@01@Z llvm-svn: 256622
2015-12-30 13:13:03 +08:00
PassObjectSizeArgs.swap(OuterPassObjectSizeArgs);
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::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) {
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?";
[MS ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
// This CXXUuidofExpr is mangled as-if it were actually a VarDecl from
// const __s_GUID _GUID_{lower case UUID with underscores}
Fix serialization/deserialization for __uuidof I broke this back in r264529 because I forgot to serialize the UuidAttr member. Fix this by replacing the UuidAttr with a StringRef which is properly serialized and deserialized. llvm-svn: 264562
2016-03-28 11:19:50 +08:00
StringRef Uuid = UE->getUuidStr();
[MS ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
std::string Name = "_GUID_" + Uuid.lower();
std::replace(Name.begin(), Name.end(), '-', '_');
mangleSourceName(Name);
// Terminate the whole name with an '@'.
Out << '@';
// It's a global variable.
Out << '3';
// It's a struct called __s_GUID.
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "__s_GUID");
[MS ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
// It's const.
Out << 'B';
[-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
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!");
ms: Insert $$Z in mangling between directly consecutive parameter packs. Fixes PR38783. Differential Revision: https://reviews.llvm.org/D51784 llvm-svn: 341755
2018-09-09 04:58:39 +08:00
for (size_t i = 0; i < TemplateArgs.size(); ++i) {
const TemplateArgument &TA = TemplateArgs[i];
// Separate consecutive packs by $$Z.
if (i > 0 && TA.getKind() == TemplateArgument::Pack &&
TemplateArgs[i - 1].getKind() == TemplateArgument::Pack)
Out << "$$Z";
mangleTemplateArg(TD, TA, TPL->getParam(i));
}
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: {
Remove redundant casts. NFC So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
2018-03-01 13:43:23 +08:00
const NamedDecl *ND = 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)) {
wrap to 80 cols, no behavior change llvm-svn: 338520
2018-08-01 19:56:20 +08:00
mangleMemberDataPointer(cast<CXXRecordDecl>(ND->getDeclContext())
->getMostRecentNonInjectedDecl(),
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()) {
wrap to 80 cols, no behavior change llvm-svn: 338520
2018-08-01 19:56:20 +08:00
mangleMemberFunctionPointer(
MD->getParent()->getMostRecentNonInjectedDecl(), 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] Correctly mangle nullptr member pointers for variable templates Variable templates behave the same as class templates with regard to nullptr memeber pointers. llvm-svn: 254439
2015-12-02 03:13:51 +08:00
if (MPT->isMemberFunctionPointerType() &&
!isa<FunctionTemplateDecl>(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] Correctly mangle nullptr member pointers for variable templates Variable templates behave the same as class templates with regard to nullptr memeber pointers. llvm-svn: 254439
2015-12-02 03:13:51 +08:00
if (!isa<FunctionTemplateDecl>(TD)) {
[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
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
}
AST: support ObjC lifetime qualifiers in MS ABI Adjust the ObjC protocol conformance workaround to be more extensible. Use a synthetic type for the protocol (`struct Protocol`). Embed this within a reserved namespace to permit extending the extended pointer type qualifiers similarly for ObjC lifetime qualifiers. Introduce additional special handling for `__autoreleasing`, `__strong`, and `__weak` Objective C lifetime qualifiers. We decorate these by creating an artificial template type `Autoreleasing`, `Strong`, or `Weak` in the `__ObjC` namespace. These are only considered in the template type specialization and not the function parameter. llvm-svn: 324701
2018-02-09 11:23:54 +08:00
void MicrosoftCXXNameMangler::mangleObjCProtocol(const ObjCProtocolDecl *PD) {
llvm::SmallString<64> TemplateMangling;
llvm::raw_svector_ostream Stream(TemplateMangling);
MicrosoftCXXNameMangler Extra(Context, Stream);
Stream << "?$";
Extra.mangleSourceName("Protocol");
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
Extra.mangleArtificialTagType(TTK_Struct, PD->getName());
AST: support ObjC lifetime qualifiers in MS ABI Adjust the ObjC protocol conformance workaround to be more extensible. Use a synthetic type for the protocol (`struct Protocol`). Embed this within a reserved namespace to permit extending the extended pointer type qualifiers similarly for ObjC lifetime qualifiers. Introduce additional special handling for `__autoreleasing`, `__strong`, and `__weak` Objective C lifetime qualifiers. We decorate these by creating an artificial template type `Autoreleasing`, `Strong`, or `Weak` in the `__ObjC` namespace. These are only considered in the template type specialization and not the function parameter. llvm-svn: 324701
2018-02-09 11:23:54 +08:00
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, TemplateMangling, {"__ObjC"});
AST: support ObjC lifetime qualifiers in MS ABI Adjust the ObjC protocol conformance workaround to be more extensible. Use a synthetic type for the protocol (`struct Protocol`). Embed this within a reserved namespace to permit extending the extended pointer type qualifiers similarly for ObjC lifetime qualifiers. Introduce additional special handling for `__autoreleasing`, `__strong`, and `__weak` Objective C lifetime qualifiers. We decorate these by creating an artificial template type `Autoreleasing`, `Strong`, or `Weak` in the `__ObjC` namespace. These are only considered in the template type specialization and not the function parameter. llvm-svn: 324701
2018-02-09 11:23:54 +08:00
}
void MicrosoftCXXNameMangler::mangleObjCLifetime(const QualType Type,
Qualifiers Quals,
SourceRange Range) {
llvm::SmallString<64> TemplateMangling;
llvm::raw_svector_ostream Stream(TemplateMangling);
MicrosoftCXXNameMangler Extra(Context, Stream);
Stream << "?$";
switch (Quals.getObjCLifetime()) {
case Qualifiers::OCL_None:
case Qualifiers::OCL_ExplicitNone:
break;
case Qualifiers::OCL_Autoreleasing:
Extra.mangleSourceName("Autoreleasing");
break;
case Qualifiers::OCL_Strong:
Extra.mangleSourceName("Strong");
break;
case Qualifiers::OCL_Weak:
Extra.mangleSourceName("Weak");
break;
}
Extra.manglePointerCVQualifiers(Quals);
Extra.manglePointerExtQualifiers(Quals, Type);
Extra.mangleType(Type, Range);
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, TemplateMangling, {"__ObjC"});
AST: support ObjC lifetime qualifiers in MS ABI Adjust the ObjC protocol conformance workaround to be more extensible. Use a synthetic type for the protocol (`struct Protocol`). Embed this within a reserved namespace to permit extending the extended pointer type qualifiers similarly for ObjC lifetime qualifiers. Introduce additional special handling for `__autoreleasing`, `__strong`, and `__weak` Objective C lifetime qualifiers. We decorate these by creating an artificial template type `Autoreleasing`, `Strong`, or `Weak` in the `__ObjC` namespace. These are only considered in the template type specialization and not the function parameter. llvm-svn: 324701
2018-02-09 11:23:54 +08:00
}
AST: add missing ObjC extensions to MS style name decoration Add support for encoding type arguments for lightweight generics in Objective-C++ mode. Additionally, add support for the `__kindof` modifier. This should complete the coverage of the ObjC extensions that clang currently supports under the MS style name decoration scheme. This is implemented similar to the Objective-C lifetime qualifiers decoration: a template specialization in the `__ObjC` namespace so that we can interoperate with Microsoft's tools as well as ensure that we do not accidentally collide with new features in the Microsoft implementation. Since the `__kindof` appertains to the type and not the pointer, we apply the template specialization to the underlying type instead of the pointer type. Unfortunately, until D52581 is resolved, the generated name is not really compatible with the MS tools as well as breaks interoperability with Objective-C++ and C++. This resolves PR37754! llvm-svn: 343338
2018-09-29 00:47:53 +08:00
void MicrosoftCXXNameMangler::mangleObjCKindOfType(const ObjCObjectType *T,
Qualifiers Quals,
SourceRange Range) {
llvm::SmallString<64> TemplateMangling;
llvm::raw_svector_ostream Stream(TemplateMangling);
MicrosoftCXXNameMangler Extra(Context, Stream);
Stream << "?$";
Extra.mangleSourceName("KindOf");
Extra.mangleType(QualType(T, 0)
.stripObjCKindOfType(getASTContext())
->getAs<ObjCObjectType>(),
Quals, Range);
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, TemplateMangling, {"__ObjC"});
AST: add missing ObjC extensions to MS style name decoration Add support for encoding type arguments for lightweight generics in Objective-C++ mode. Additionally, add support for the `__kindof` modifier. This should complete the coverage of the ObjC extensions that clang currently supports under the MS style name decoration scheme. This is implemented similar to the Objective-C lifetime qualifiers decoration: a template specialization in the `__ObjC` namespace so that we can interoperate with Microsoft's tools as well as ensure that we do not accidentally collide with new features in the Microsoft implementation. Since the `__kindof` appertains to the type and not the pointer, we apply the template specialization to the underlying type instead of the pointer type. Unfortunately, until D52581 is resolved, the generated name is not really compatible with the MS tools as well as breaks interoperability with Objective-C++ and C++. This resolves PR37754! llvm-svn: 343338
2018-09-29 00:47:53 +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) {
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';
AST: inline a single-use variable (NFC) Inline the single use variable into the only use. NFC. llvm-svn: 323461
2018-01-26 03:54:31 +08:00
if (Quals.hasRestrict())
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 << 'I';
[MSVC] Implementation of __unaligned as a proper type qualifier This patch implements __unaligned (MS extension) as a proper type qualifier (before that, it was implemented as an ignored attribute). It also fixes PR27367 and PR27666. Differential Revision: http://reviews.llvm.org/D20103 llvm-svn: 269220
2016-05-12 02:38:21 +08:00
[MSVC] Support for __unaligned qualifier in functions This implements support for MS-specific __unaligned qualifier in functions and makes the following test case both compile and mangle correctly: struct S { void f() __unaligned; }; void S::f() __unaligned { } Differential Revision: http://reviews.llvm.org/D20437 llvm-svn: 270834
2016-05-26 18:06:01 +08:00
if (Quals.hasUnaligned() ||
(!PointeeType.isNull() && PointeeType.getLocalQualifiers().hasUnaligned()))
[MSVC] Implementation of __unaligned as a proper type qualifier This patch implements __unaligned (MS extension) as a proper type qualifier (before that, it was implemented as an ignored attribute). It also fixes PR27367 and PR27666. Differential Revision: http://reviews.llvm.org/D20103 llvm-svn: 269220
2016-05-12 02:38:21 +08:00
Out << 'F';
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 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;
}
}
[MS ABI] Improve our mangling of pass_object_size We didn't add the artificial pass_object_size arguments to the backreference map which bloated the size of manglings which involved pass_object_size with duplicate types. This lets us go from: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@0W4__pass_object_size1@3@@Z to: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@01@Z llvm-svn: 256622
2015-12-30 13:13:03 +08:00
void MicrosoftCXXNameMangler::manglePassObjectSizeArg(
const PassObjectSizeAttr *POSA) {
int Type = POSA->getType();
Add a spelling of pass_object_size that uses __builtin_dynamic_object_size The attribute pass_dynamic_object_size(n) behaves exactly like pass_object_size(n), but instead of evaluating __builtin_object_size on calls, it evaluates __builtin_dynamic_object_size, which has the potential to produce runtime code when the object size can't be determined statically. Differential revision: https://reviews.llvm.org/D58757 llvm-svn: 356515
2019-03-20 04:44:18 +08:00
bool Dynamic = POSA->isDynamic();
[MS ABI] Improve our mangling of pass_object_size We didn't add the artificial pass_object_size arguments to the backreference map which bloated the size of manglings which involved pass_object_size with duplicate types. This lets us go from: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@0W4__pass_object_size1@3@@Z to: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@01@Z llvm-svn: 256622
2015-12-30 13:13:03 +08:00
Add a spelling of pass_object_size that uses __builtin_dynamic_object_size The attribute pass_dynamic_object_size(n) behaves exactly like pass_object_size(n), but instead of evaluating __builtin_object_size on calls, it evaluates __builtin_dynamic_object_size, which has the potential to produce runtime code when the object size can't be determined statically. Differential revision: https://reviews.llvm.org/D58757 llvm-svn: 356515
2019-03-20 04:44:18 +08:00
auto Iter = PassObjectSizeArgs.insert({Type, Dynamic}).first;
[MS ABI] Change the ArgBackRefMap to hold const qualified pointers Just a cleanup, no functional change is intended. llvm-svn: 256663
2015-12-31 13:36:52 +08:00
auto *TypePtr = (const void *)&*Iter;
[MS ABI] Improve our mangling of pass_object_size We didn't add the artificial pass_object_size arguments to the backreference map which bloated the size of manglings which involved pass_object_size with duplicate types. This lets us go from: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@0W4__pass_object_size1@3@@Z to: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@01@Z llvm-svn: 256622
2015-12-30 13:13:03 +08:00
ArgBackRefMap::iterator Found = TypeBackReferences.find(TypePtr);
if (Found == TypeBackReferences.end()) {
Add a spelling of pass_object_size that uses __builtin_dynamic_object_size The attribute pass_dynamic_object_size(n) behaves exactly like pass_object_size(n), but instead of evaluating __builtin_object_size on calls, it evaluates __builtin_dynamic_object_size, which has the potential to produce runtime code when the object size can't be determined statically. Differential revision: https://reviews.llvm.org/D58757 llvm-svn: 356515
2019-03-20 04:44:18 +08:00
std::string Name =
Dynamic ? "__pass_dynamic_object_size" : "__pass_object_size";
mangleArtificialTagType(TTK_Enum, Name + llvm::utostr(Type), {"__clang"});
[MS ABI] Improve our mangling of pass_object_size We didn't add the artificial pass_object_size arguments to the backreference map which bloated the size of manglings which involved pass_object_size with duplicate types. This lets us go from: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@0W4__pass_object_size1@3@@Z to: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@01@Z llvm-svn: 256622
2015-12-30 13:13:03 +08:00
if (TypeBackReferences.size() < 10) {
size_t Size = TypeBackReferences.size();
TypeBackReferences[TypePtr] = Size;
}
} else {
Out << Found->second;
}
}
Add AddressSpace mangling to MS mode All of the symbols demangle on llvm-undname and demangler.com. This address space qualifier is useful for when we want to use opencl C++ in Windows mode. Additionally, C++ address-space using functions will now be usable on windows. Differential Revision: https://reviews.llvm.org/D55715 Change-Id: Ife4506613c3cce778a783456d62117fbf7d83c26 llvm-svn: 349209
2018-12-15 07:17:34 +08:00
void MicrosoftCXXNameMangler::mangleAddressSpaceType(QualType T,
Qualifiers Quals,
SourceRange Range) {
// Address space is mangled as an unqualified templated type in the __clang
// namespace. The demangled version of this is:
// In the case of a language specific address space:
// __clang::struct _AS[language_addr_space]<Type>
// where:
// <language_addr_space> ::= <OpenCL-addrspace> | <CUDA-addrspace>
// <OpenCL-addrspace> ::= "CL" [ "global" | "local" | "constant" |
// "private"| "generic" ]
// <CUDA-addrspace> ::= "CU" [ "device" | "constant" | "shared" ]
// Note that the above were chosen to match the Itanium mangling for this.
//
// In the case of a non-language specific address space:
// __clang::struct _AS<TargetAS, Type>
assert(Quals.hasAddressSpace() && "Not valid without address space");
llvm::SmallString<32> ASMangling;
llvm::raw_svector_ostream Stream(ASMangling);
MicrosoftCXXNameMangler Extra(Context, Stream);
Stream << "?$";
LangAS AS = Quals.getAddressSpace();
if (Context.getASTContext().addressSpaceMapManglingFor(AS)) {
unsigned TargetAS = Context.getASTContext().getTargetAddressSpace(AS);
Extra.mangleSourceName("_AS");
Extra.mangleIntegerLiteral(llvm::APSInt::getUnsigned(TargetAS),
/*IsBoolean*/ false);
} else {
switch (AS) {
default:
llvm_unreachable("Not a language specific address space");
case LangAS::opencl_global:
Extra.mangleSourceName("_ASCLglobal");
break;
case LangAS::opencl_local:
Extra.mangleSourceName("_ASCLlocal");
break;
case LangAS::opencl_constant:
Extra.mangleSourceName("_ASCLconstant");
break;
case LangAS::opencl_private:
Extra.mangleSourceName("_ASCLprivate");
break;
case LangAS::opencl_generic:
Extra.mangleSourceName("_ASCLgeneric");
break;
case LangAS::cuda_device:
Extra.mangleSourceName("_ASCUdevice");
break;
case LangAS::cuda_constant:
Extra.mangleSourceName("_ASCUconstant");
break;
case LangAS::cuda_shared:
Extra.mangleSourceName("_ASCUshared");
break;
}
}
Extra.mangleType(T, Range, QMM_Escape);
mangleQualifiers(Qualifiers(), false);
mangleArtificialTagType(TTK_Struct, ASMangling, {"__clang"});
}
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(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();
Add AddressSpace mangling to MS mode All of the symbols demangle on llvm-undname and demangler.com. This address space qualifier is useful for when we want to use opencl C++ in Windows mode. Additionally, C++ address-space using functions will now be usable on windows. Differential Revision: https://reviews.llvm.org/D55715 Change-Id: Ife4506613c3cce778a783456d62117fbf7d83c26 llvm-svn: 349209
2018-12-15 07:17:34 +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
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:
AST: support ObjC lifetime qualifiers in MS ABI Adjust the ObjC protocol conformance workaround to be more extensible. Use a synthetic type for the protocol (`struct Protocol`). Embed this within a reserved namespace to permit extending the extended pointer type qualifiers similarly for ObjC lifetime qualifiers. Introduce additional special handling for `__autoreleasing`, `__strong`, and `__weak` Objective C lifetime qualifiers. We decorate these by creating an artificial template type `Autoreleasing`, `Strong`, or `Weak` in the `__ObjC` namespace. These are only considered in the template type specialization and not the function parameter. llvm-svn: 324701
2018-02-09 11:23:54 +08:00
if (Quals.hasObjCLifetime())
Quals = Quals.withoutObjCLifetime();
[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
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:
[MSVC] Implementation of __unaligned as a proper type qualifier This patch implements __unaligned (MS extension) as a proper type qualifier (before that, it was implemented as an ignored attribute). It also fixes PR27367 and PR27666. Differential Revision: http://reviews.llvm.org/D20103 llvm-svn: 269220
2016-05-12 02:38:21 +08:00
// Presence of __unaligned qualifier shouldn't affect mangling here.
Quals.removeUnaligned();
AST: support ObjC lifetime qualifiers in MS ABI Adjust the ObjC protocol conformance workaround to be more extensible. Use a synthetic type for the protocol (`struct Protocol`). Embed this within a reserved namespace to permit extending the extended pointer type qualifiers similarly for ObjC lifetime qualifiers. Introduce additional special handling for `__autoreleasing`, `__strong`, and `__weak` Objective C lifetime qualifiers. We decorate these by creating an artificial template type `Autoreleasing`, `Strong`, or `Weak` in the `__ObjC` namespace. These are only considered in the template type specialization and not the function parameter. llvm-svn: 324701
2018-02-09 11:23:54 +08:00
if (Quals.hasObjCLifetime())
Quals = Quals.withoutObjCLifetime();
[ms] Fix mangling of vector types in QMM_Result contexts. If QMM_Result is set (which it is for return types, RTTI descriptors, and exception type descriptors), tag types (structs, enums, classes, unions) get their qualifiers mangled in. __m64 and friends is a struct/union thingy in MSVC, but not in clang's headers. To make mangling work, we call mangleArtificalTagType(TTK_Union/TTK_Struct for the vector types to mangle them as tag types -- but the isa<TagType> check when mangling in QMM_Result mode isn't true for these vector types. Add an isArtificialTagType() function and check for that too. Fixes PR37276 and some other issues. I tried to audit all references to TagDecl and TagType in MicrosoftMangle.cpp to find other places where we need to call mangleArtificalTagType(), but couldn't find any. I tried to audit all calls to mangleArtificalTagType() to see if isArtificialTagType() needs to handle more than just the vector types, but as far as I can tell all other types we use it for are types that MSVC can't handle at all (Objective-C types etc). https://reviews.llvm.org/D49597 llvm-svn: 337732
2018-07-24 04:04:00 +08:00
if ((!IsPointer && Quals) || isa<TagType>(T) || isArtificialTagType(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
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>
Use _Q as MS ABI mangling for char8_t. Thanks to Yuriy Solodkyy for letting us know the mangling here. llvm-svn: 354633
2019-02-22 07:04:35 +08:00
// ::= _Q # char8_t
Update MS mangling EBNF, NFC llvm-svn: 304006
2017-05-27 01:11:10 +08:00
// ::= _S # char16_t
Use _Q as MS ABI mangling for char8_t. Thanks to Yuriy Solodkyy for letting us know the mangling here. llvm-svn: 354633
2019-02-22 07:04:35 +08:00
// ::= _T # __float80 (Intel)
Update MS mangling EBNF, NFC llvm-svn: 304006
2017-05-27 01:11:10 +08:00
// ::= _U # char32_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
// ::= _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;
Use _Q as MS ABI mangling for char8_t. Thanks to Yuriy Solodkyy for letting us know the mangling here. llvm-svn: 354633
2019-02-22 07:04:35 +08:00
case BuiltinType::Char8:
Out << "_Q";
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::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:
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "objc_object");
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
break;
case BuiltinType::ObjCClass:
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "objc_class");
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
break;
case BuiltinType::ObjCSel:
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "objc_selector");
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
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
[OpenCL] Complete image types support. I. Current implementation of images is not conformant to spec in the following points: 1. It makes no distinction with respect to access qualifiers and therefore allows to use images with different access type interchangeably. The following code would compile just fine: void write_image(write_only image2d_t img); kernel void foo(read_only image2d_t img) { write_image(img); } // Accepted code which is disallowed according to s6.13.14. 2. It discards access qualifier on generated code, which leads to generated code for the above example: call void @write_image(%opencl.image2d_t* %img); In OpenCL2.0 however we can have different calls into write_image with read_only and wite_only images. Also generally following compiler steps have no easy way to take different path depending on the image access: linking to the right implementation of image types, performing IR opts and backend codegen differently. 3. Image types are language keywords and can't be redeclared s6.1.9, which can happen currently as they are just typedef names. 4. Default access qualifier read_only is to be added if not provided explicitly. II. This patch corrects the above points as follows: 1. All images are encapsulated into a separate .def file that is inserted in different points where image handling is required. This avoid a lot of code repetition as all images are handled the same way in the code with no distinction of their exact type. 2. The Cartesian product of image types and image access qualifiers is added to the builtin types. This simplifies a lot handling of access type mismatch as no operations are allowed by default on distinct Builtin types. Also spec intended access qualifier as special type qualifier that are combined with an image type to form a distinct type (see statement above - images can't be created w/o access qualifiers). 3. Improves testing of images in Clang. Author: Anastasia Stulova Reviewers: bader, mgrang. Subscribers: pxli168, pekka.jaaskelainen, yaxunl. Differential Revision: http://reviews.llvm.org/D17821 llvm-svn: 265783
2016-04-08 21:40:33 +08:00
#define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) \
case BuiltinType::Id: \
Out << "PAUocl_" #ImgType "_" #Suffix "@@"; \
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
break;
[OpenCL] Move OpenCLImageTypes.def from clangAST to clangBasic library. Putting OpenCLImageTypes.def to clangAST library violates layering requirement: "It's not OK for a Basic/ header to include an AST/ header". This fixes the modules build. Differential revision: http://reviews.llvm.org/D18954 Reviewers: Richard Smith, Vassil Vassilev. llvm-svn: 266180
2016-04-13 16:33:41 +08:00
#include "clang/Basic/OpenCLImageTypes.def"
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::OCLSampler:
[MS ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
Out << "PA";
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "ocl_sampler");
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
break;
case BuiltinType::OCLEvent:
[MS ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
Out << "PA";
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "ocl_event");
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
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:
[MS ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
Out << "PA";
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "ocl_clkevent");
[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
break;
case BuiltinType::OCLQueue:
[MS ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
Out << "PA";
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "ocl_queue");
[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
break;
case BuiltinType::OCLReserveID:
[MS ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
Out << "PA";
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "ocl_reserveid");
[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
break;
[OpenCL] Add support of cl_intel_device_side_avc_motion_estimation extension Summary: Documentation can be found at https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_device_side_avc_motion_estimation.txt Patch by Kristina Bessonova Reviewers: Anastasia, yaxunl, shafik Reviewed By: Anastasia Subscribers: arphaman, sidorovd, AlexeySotkin, krisb, bader, asavonic, cfe-commits Differential Revision: https://reviews.llvm.org/D51484 llvm-svn: 346392
2018-11-08 19:25:41 +08:00
#define EXT_OPAQUE_TYPE(ExtType, Id, Ext) \
case BuiltinType::Id: \
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "ocl_" #ExtType); \
[OpenCL] Add support of cl_intel_device_side_avc_motion_estimation extension Summary: Documentation can be found at https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_device_side_avc_motion_estimation.txt Patch by Kristina Bessonova Reviewers: Anastasia, yaxunl, shafik Reviewed By: Anastasia Subscribers: arphaman, sidorovd, AlexeySotkin, krisb, bader, asavonic, cfe-commits Differential Revision: https://reviews.llvm.org/D51484 llvm-svn: 346392
2018-11-08 19:25:41 +08:00
break;
#include "clang/Basic/OpenCLExtensionTypes.def"
[-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
Recommit "Add _Float16 as a C/C++ source language type" This is a recommit of r312781; in some build configurations variable names are omitted, so changed the new regression test accordingly. llvm-svn: 312794
2017-09-08 23:15:00 +08:00
case BuiltinType::Float16:
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "_Float16", {"__clang"});
Add Microsoft mangling for _Float16 Enables _Float16 on Windows by creating a mangling mechanism in MicrosoftMangle. It accomplishes this by mangling as a structure type of __clang::_Float16, similar to how Complex works. Patch By: mibintc Differential Revision: https://reviews.llvm.org/D45738 llvm-svn: 330225
2018-04-18 06:00:54 +08:00
break;
Add Microsoft Mangling for OpenCL Half Type Half-type mangling is accomplished following the method introduced by Erich Keane for mangling _Float16. Updated the half.cl LIT test to cover this particular case. Patch By: vbridgers Differential Revision: https://reviews.llvm.org/D46131 llvm-svn: 331263
2018-05-01 22:16:15 +08:00
case BuiltinType::Half:
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "_Half", {"__clang"});
Add Microsoft Mangling for OpenCL Half Type Half-type mangling is accomplished following the method introduced by Erich Keane for mangling _Float16. Updated the half.cl LIT test to cover this particular case. Patch By: vbridgers Differential Revision: https://reviews.llvm.org/D46131 llvm-svn: 331263
2018-05-01 22:16:15 +08:00
break;
This diff includes changes for supporting the following types. // Primary fixed point types signed short _Accum s_short_accum; signed _Accum s_accum; signed long _Accum s_long_accum; unsigned short _Accum u_short_accum; unsigned _Accum u_accum; unsigned long _Accum u_long_accum; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent _Fract types will also be added in future patches. The tests included are for asserting that we can declare these types. Fixed the test that was failing by not checking for dso_local on some targets. Differential Revision: https://reviews.llvm.org/D46084 llvm-svn: 333923
2018-06-05 00:07:52 +08:00
case BuiltinType::ShortAccum:
case BuiltinType::Accum:
case BuiltinType::LongAccum:
case BuiltinType::UShortAccum:
case BuiltinType::UAccum:
case BuiltinType::ULongAccum:
[Fixed Point Arithmetic] Addition of the remaining fixed point types and their saturated equivalents This diff includes changes for the remaining _Fract and _Sat fixed point types. ``` signed short _Fract s_short_fract; signed _Fract s_fract; signed long _Fract s_long_fract; unsigned short _Fract u_short_fract; unsigned _Fract u_fract; unsigned long _Fract u_long_fract; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; short _Fract short_fract; _Fract fract; long _Fract long_fract; // Saturated fixed point types _Sat signed short _Accum sat_s_short_accum; _Sat signed _Accum sat_s_accum; _Sat signed long _Accum sat_s_long_accum; _Sat unsigned short _Accum sat_u_short_accum; _Sat unsigned _Accum sat_u_accum; _Sat unsigned long _Accum sat_u_long_accum; _Sat signed short _Fract sat_s_short_fract; _Sat signed _Fract sat_s_fract; _Sat signed long _Fract sat_s_long_fract; _Sat unsigned short _Fract sat_u_short_fract; _Sat unsigned _Fract sat_u_fract; _Sat unsigned long _Fract sat_u_long_fract; // Aliased saturated fixed point types _Sat short _Accum sat_short_accum; _Sat _Accum sat_accum; _Sat long _Accum sat_long_accum; _Sat short _Fract sat_short_fract; _Sat _Fract sat_fract; _Sat long _Fract sat_long_fract; ``` This diff only allows for declaration of these fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. Differential Revision: https://reviews.llvm.org/D46911 llvm-svn: 334718
2018-06-14 22:53:51 +08:00
case BuiltinType::ShortFract:
case BuiltinType::Fract:
case BuiltinType::LongFract:
case BuiltinType::UShortFract:
case BuiltinType::UFract:
case BuiltinType::ULongFract:
case BuiltinType::SatShortAccum:
case BuiltinType::SatAccum:
case BuiltinType::SatLongAccum:
case BuiltinType::SatUShortAccum:
case BuiltinType::SatUAccum:
case BuiltinType::SatULongAccum:
case BuiltinType::SatShortFract:
case BuiltinType::SatFract:
case BuiltinType::SatLongFract:
case BuiltinType::SatUShortFract:
case BuiltinType::SatUFract:
case BuiltinType::SatULongFract:
Add Microsoft Mangling for OpenCL Half Type Half-type mangling is accomplished following the method introduced by Erich Keane for mangling _Float16. Updated the half.cl LIT test to cover this particular case. Patch By: vbridgers Differential Revision: https://reviews.llvm.org/D46131 llvm-svn: 331263
2018-05-01 22:16:15 +08:00
case BuiltinType::Float128: {
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();
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.
Rename getTypeQualifiers to getMethodQualifiers. Use more descriptive name for the method qualifiers getter. Differential Revision: https://reviews.llvm.org/D56792 llvm-svn: 352349
2019-01-28 19:37:49 +08:00
if (T->getMethodQuals() || T->getRefQualifier() != RQ_None) {
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
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,
Update Microsoft name mangling scheme for exception specifiers in the type system Summary: The msvc exception specifier for noexcept function types has changed from the prior default of "Z" to "_E" if the function cannot throw when compiling with /std:C++17. Patch by Zachary Henkel! Reviewers: zturner, rnk Reviewed By: rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55685 llvm-svn: 349414
2018-12-18 07:10:43 +08:00
bool ForceThisQuals,
bool MangleExceptionSpec) {
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] Don't crash while mangling recursive lambdas We might get into bad situations where we try to embed the signature of an inner lambda into an outer lambda which cannot work: the inner lambda wants to embed the name of the outer lambda! Instead, omit the return type for lambdas. This fixes PR26105. N.B. While we are here, make lambdas nested within functions use an artificial scope so that they can get demangled. llvm-svn: 258003
2016-01-17 15:09:24 +08:00
bool IsInLambda = false;
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)) {
[MS ABI] Don't crash while mangling recursive lambdas We might get into bad situations where we try to embed the signature of an inner lambda into an outer lambda which cannot work: the inner lambda wants to embed the name of the outer lambda! Instead, omit the return type for lambdas. This fixes PR26105. N.B. While we are here, make lambdas nested within functions use an artificial scope so that they can get demangled. llvm-svn: 258003
2016-01-17 15:09:24 +08:00
if (MD->getParent()->isLambda())
IsInLambda = true;
Simplify MicrosoftCXXNameMangler::mangleFunctionType llvm-svn: 191950
2013-10-04 19:25:05 +08:00
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) &&
[MS] Fix function type mangling of default ctor closures Use the canonical decl in pointer comparisons with the default constructor closure decl. Otherwise we don't produce the correct "@@QAEXXZ" mangling, which essentially means "void(void) thiscall public instance method". llvm-svn: 291448
2017-01-10 01:04:37 +08:00
isStructorDecl(MD);
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)
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) {
Rename getTypeQualifiers to getMethodQualifiers. Use more descriptive name for the method qualifiers getter. Differential Revision: https://reviews.llvm.org/D56792 llvm-svn: 352349
2019-01-28 19:37:49 +08:00
Qualifiers Quals = Proto->getMethodQuals();
[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) {
[MS ABI] Correctly mangling vbase destructors They are a little bit of a special case in the mangling. They are always mangled without taking into account their virtual-ness of the destructor. They are also mangled to return void, unlike the actual destructor. This fixes PR31931. Differential Revision: https://reviews.llvm.org/D29912 llvm-svn: 295010
2017-02-14 08:54:11 +08:00
if (isa<CXXDestructorDecl>(D) && isStructorDecl(D)) {
// The scalar deleting destructor takes an extra int argument which is not
// reflected in the AST.
if (StructorType == Dtor_Deleting) {
Out << (PointersAre64Bit ? "PEAXI@Z" : "PAXI@Z");
return;
}
// The vbase destructor returns void which is not reflected in the AST.
if (StructorType == Dtor_Complete) {
Out << "XXZ";
return;
}
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
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 << '?';
Add support for GCC's '__auto_type' extension, per the GCC manual: https://gcc.gnu.org/onlinedocs/gcc/Typeof.html Differences from the GCC extension: * __auto_type is also permitted in C++ (but only in places where it could appear in C), allowing its use in headers that might be shared across C and C++, or used from C++98 * __auto_type can be combined with a declarator, as with C++ auto (for instance, "__auto_type *p") * multiple variables can be declared in a single __auto_type declaration, with the C++ semantics (the deduced type must be the same in each case) This patch also adds a missing restriction on applying typeof to a bit-field, which GCC has historically rejected in C (due to lack of clarity as to whether the operand should be promoted). The same restriction also applies to __auto_type in C (in both GCC and Clang). This also fixes PR25449. Patch by Nicholas Allegra! llvm-svn: 252690
2015-11-11 10:02:15 +08:00
assert(AT->getKeyword() != AutoTypeKeyword::GNUAutoType &&
"shouldn't need to mangle __auto_type!");
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
mangleSourceName(AT->isDecltypeAuto() ? "<decltype-auto>" : "<auto>");
Out << '@';
[MS ABI] Don't crash while mangling recursive lambdas We might get into bad situations where we try to embed the signature of an inner lambda into an outer lambda which cannot work: the inner lambda wants to embed the name of the outer lambda! Instead, omit the return type for lambdas. This fixes PR26105. N.B. While we are here, make lambdas nested within functions use an artificial scope so that they can get demangled. llvm-svn: 258003
2016-01-17 15:09:24 +08:00
} else if (IsInLambda) {
Out << '@';
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
} 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.
Add the `pass_object_size` attribute to clang. `pass_object_size` is our way of enabling `__builtin_object_size` to produce high quality results without requiring inlining to happen everywhere. A link to the design doc for this attribute is available at the Differential review link below. Differential Revision: http://reviews.llvm.org/D13263 llvm-svn: 254554
2015-12-03 05:58:08 +08:00
for (unsigned I = 0, E = Proto->getNumParams(); I != E; ++I) {
mangleArgumentType(Proto->getParamType(I), Range);
Fix spelling mistake - paramater -> parameter. NFCI. llvm-svn: 295183
2017-02-15 23:12:06 +08:00
// Mangle each pass_object_size parameter as if it's a parameter of enum
Add the `pass_object_size` attribute to clang. `pass_object_size` is our way of enabling `__builtin_object_size` to produce high quality results without requiring inlining to happen everywhere. A link to the design doc for this attribute is available at the Differential review link below. Differential Revision: http://reviews.llvm.org/D13263 llvm-svn: 254554
2015-12-03 05:58:08 +08:00
// type passed directly after the parameter with the pass_object_size
// attribute. The aforementioned enum's name is __pass_object_size, and we
// pretend it resides in a top-level namespace called __clang.
//
// FIXME: Is there a defined extension notation for the MS ABI, or is it
// necessary to just cross our fingers and hope this type+namespace
// combination doesn't conflict with anything?
if (D)
[MS ABI] Improve our mangling of pass_object_size We didn't add the artificial pass_object_size arguments to the backreference map which bloated the size of manglings which involved pass_object_size with duplicate types. This lets us go from: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@0W4__pass_object_size1@3@@Z to: ?qux@PassObjectSize@@YAHQAHW4__pass_object_size1@__clang@@01@Z llvm-svn: 256622
2015-12-30 13:13:03 +08:00
if (const auto *P = D->getParamDecl(I)->getAttr<PassObjectSizeAttr>())
manglePassObjectSizeArg(P);
Add the `pass_object_size` attribute to clang. `pass_object_size` is our way of enabling `__builtin_object_size` to produce high quality results without requiring inlining to happen everywhere. A link to the design doc for this attribute is available at the Differential review link below. Differential Revision: http://reviews.llvm.org/D13263 llvm-svn: 254554
2015-12-03 05:58: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
// <builtin-type> ::= Z # ellipsis
if (Proto->isVariadic())
Out << 'Z';
else
Out << '@';
}
Update Microsoft name mangling scheme for exception specifiers in the type system Summary: The msvc exception specifier for noexcept function types has changed from the prior default of "Z" to "_E" if the function cannot throw when compiling with /std:C++17. Patch by Zachary Henkel! Reviewers: zturner, rnk Reviewed By: rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55685 llvm-svn: 349414
2018-12-18 07:10:43 +08:00
if (MangleExceptionSpec && getASTContext().getLangOpts().CPlusPlus17 &&
getASTContext().getLangOpts().isCompatibleWithMSVC(
LangOptions::MSVC2017_5))
mangleThrowSpecification(Proto);
else
Out << 'Z';
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::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)) {
[MS ABI] Correctly mangling vbase destructors They are a little bit of a special case in the mangling. They are always mangled without taking into account their virtual-ness of the destructor. They are also mangled to return void, unlike the actual destructor. This fixes PR31931. Differential Revision: https://reviews.llvm.org/D29912 llvm-svn: 295010
2017-02-14 08:54:11 +08:00
bool IsVirtual = MD->isVirtual();
// When mangling vbase destructor variants, ignore whether or not the
// underlying destructor was defined to be virtual.
if (isa<CXXDestructorDecl>(MD) && isStructorDecl(MD) &&
StructorType == Dtor_Complete) {
IsVirtual = 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
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';
[MS ABI] Correctly mangling vbase destructors They are a little bit of a special case in the mangling. They are always mangled without taking into account their virtual-ness of the destructor. They are also mangled to return void, unlike the actual destructor. This fixes PR31931. Differential Revision: https://reviews.llvm.org/D29912 llvm-svn: 295010
2017-02-14 08:54:11 +08:00
else if (IsVirtual)
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';
else
Out << 'A';
break;
case AS_protected:
if (MD->isStatic())
Out << 'K';
[MS ABI] Correctly mangling vbase destructors They are a little bit of a special case in the mangling. They are always mangled without taking into account their virtual-ness of the destructor. They are also mangled to return void, unlike the actual destructor. This fixes PR31931. Differential Revision: https://reviews.llvm.org/D29912 llvm-svn: 295010
2017-02-14 08:54:11 +08:00
else if (IsVirtual)
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 << 'M';
else
Out << 'I';
break;
case AS_public:
if (MD->isStatic())
Out << 'S';
[MS ABI] Correctly mangling vbase destructors They are a little bit of a special case in the mangling. They are always mangled without taking into account their virtual-ness of the destructor. They are also mangled to return void, unlike the actual destructor. This fixes PR31931. Differential Revision: https://reviews.llvm.org/D29912 llvm-svn: 295010
2017-02-14 08:54:11 +08:00
else if (IsVirtual)
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 << '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
regcall: Implement regcall Calling Conv in clang This patch implements the register call calling convention, which ensures as many values as possible are passed in registers. CodeGen changes were committed in https://reviews.llvm.org/rL284108. Differential Revision: https://reviews.llvm.org/D25204 llvm-svn: 285849
2016-11-03 02:29:35 +08:00
// ::= w # __regcall
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");
[AArch64] Add support for __builtin_ms_va_list on aarch64 Move builtins from the x86 specific scope into the global scope. Their use is still limited to x86_64 and aarch64 though. This allows wine on aarch64 to properly handle variadic functions. Differential Revision: https://reviews.llvm.org/D34475 llvm-svn: 308218
2017-07-18 04:49:45 +08:00
case CC_Win64:
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_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;
AST: support SwiftCC on MS ABI Microsoft has reserved the identifier 'S' as the swift calling convention. Decorate the symbols appropriately. This enables swift on Windows. llvm-svn: 324439
2018-02-07 09:55:08 +08:00
case CC_Swift: Out << 'S'; break;
CodeGenCXX: support PreserveMostCC in MS ABI Microsoft has reserved 'U' for the PreserveMostCC which is used in the swift runtime. Add support for this. This allows the swift runtime to be built for Windows again. llvm-svn: 329025
2018-04-03 06:25:50 +08:00
case CC_PreserveMost: Out << 'U'; break;
regcall: Implement regcall Calling Conv in clang This patch implements the register call calling convention, which ensures as many values as possible are passed in registers. CodeGen changes were committed in https://reviews.llvm.org/rL284108. Differential Revision: https://reviews.llvm.org/D25204 llvm-svn: 285849
2016-11-03 02:29:35 +08:00
case CC_X86RegCall: 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
}
}
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());
}
Update Microsoft name mangling scheme for exception specifiers in the type system Summary: The msvc exception specifier for noexcept function types has changed from the prior default of "Z" to "_E" if the function cannot throw when compiling with /std:C++17. Patch by Zachary Henkel! Reviewers: zturner, rnk Reviewed By: rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55685 llvm-svn: 349414
2018-12-18 07:10:43 +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::mangleThrowSpecification(
const FunctionProtoType *FT) {
Update Microsoft name mangling scheme for exception specifiers in the type system Summary: The msvc exception specifier for noexcept function types has changed from the prior default of "Z" to "_E" if the function cannot throw when compiling with /std:C++17. Patch by Zachary Henkel! Reviewers: zturner, rnk Reviewed By: rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55685 llvm-svn: 349414
2018-12-18 07:10:43 +08:00
// <throw-spec> ::= Z # (default)
// ::= _E # noexcept
if (FT->canThrow())
Out << 'Z';
else
Out << "_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
}
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] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
void MicrosoftCXXNameMangler::mangleTagTypeKind(TagTypeKind TTK) {
switch (TTK) {
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 ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
}
void MicrosoftCXXNameMangler::mangleType(const EnumType *T, Qualifiers,
SourceRange) {
mangleType(cast<TagType>(T)->getDecl());
}
void MicrosoftCXXNameMangler::mangleType(const RecordType *T, Qualifiers,
SourceRange) {
mangleType(cast<TagType>(T)->getDecl());
}
void MicrosoftCXXNameMangler::mangleType(const TagDecl *TD) {
mangleTagTypeKind(TD->getTagKind());
[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
}
[ms] Fix mangling of vector types in QMM_Result contexts. If QMM_Result is set (which it is for return types, RTTI descriptors, and exception type descriptors), tag types (structs, enums, classes, unions) get their qualifiers mangled in. __m64 and friends is a struct/union thingy in MSVC, but not in clang's headers. To make mangling work, we call mangleArtificalTagType(TTK_Union/TTK_Struct for the vector types to mangle them as tag types -- but the isa<TagType> check when mangling in QMM_Result mode isn't true for these vector types. Add an isArtificialTagType() function and check for that too. Fixes PR37276 and some other issues. I tried to audit all references to TagDecl and TagType in MicrosoftMangle.cpp to find other places where we need to call mangleArtificalTagType(), but couldn't find any. I tried to audit all calls to mangleArtificalTagType() to see if isArtificialTagType() needs to handle more than just the vector types, but as far as I can tell all other types we use it for are types that MSVC can't handle at all (Objective-C types etc). https://reviews.llvm.org/D49597 llvm-svn: 337732
2018-07-24 04:04:00 +08:00
// If you add a call to this, consider updating isArtificialTagType() too.
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
void MicrosoftCXXNameMangler::mangleArtificialTagType(
wrap to 80 cols, no behavior change llvm-svn: 338520
2018-08-01 19:56:20 +08:00
TagTypeKind TK, StringRef UnqualifiedName,
ArrayRef<StringRef> NestedNames) {
[MS ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
// <name> ::= <unscoped-name> {[<named-scope>]+ | [<nested-name>]}? @
mangleTagTypeKind(TK);
// Always start with the unqualified name.
mangleSourceName(UnqualifiedName);
for (auto I = NestedNames.rbegin(), E = NestedNames.rend(); I != E; ++I)
mangleSourceName(*I);
// Terminate the whole name with an '@'.
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
// <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>
wrap to 80 cols, no behavior change llvm-svn: 338520
2018-08-01 19:56:20 +08:00
void MicrosoftCXXNameMangler::mangleType(const MemberPointerType *T,
Qualifiers Quals, 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
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);
Add AddressSpace mangling to MS mode All of the symbols demangle on llvm-undname and demangler.com. This address space qualifier is useful for when we want to use opencl C++ in Windows mode. Additionally, C++ address-space using functions will now be usable on windows. Differential Revision: https://reviews.llvm.org/D55715 Change-Id: Ife4506613c3cce778a783456d62117fbf7d83c26 llvm-svn: 349209
2018-12-15 07:17:34 +08:00
if (PointeeType.getQualifiers().hasAddressSpace())
mangleAddressSpaceType(PointeeType, PointeeType.getQualifiers(), Range);
else
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
}
ObjC++: decorate ObjC interfaces in MSABI properly `id` needs to be handled specially since it is a `TypedefType` which is sugar for an `ObjCObjectPointerType` whose pointee is an `ObjCObjectType` with base `BuiltinType::ObjCIdType` and no protocols and the first level of pointer gets it own type implementation. `Class` is similar with the `ObjCClassType` as the base instead. The qualifiers on the base type of the `ObjCObjectType` need to be dropped because the innermost `mangleType` will handle the qualifiers itself. `id` is desugared to `struct objc_object *` which should be encoded as `PAUobjc_object@@`. `Class` is desugared to `struct objc_class *` which should be encoded as `PAUobjc_class@@`. We were previously applying an extra modifier `A` which will be handled during the recursive call. This now properly decorates interface types as well as `Class` and `id`. This corrects the interactions between C++ and ObjC++ for the type specifier decoration. llvm-svn: 311617
2017-08-24 06:38:58 +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::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();
AST: support ObjC lifetime qualifiers in MS ABI Adjust the ObjC protocol conformance workaround to be more extensible. Use a synthetic type for the protocol (`struct Protocol`). Embed this within a reserved namespace to permit extending the extended pointer type qualifiers similarly for ObjC lifetime qualifiers. Introduce additional special handling for `__autoreleasing`, `__strong`, and `__weak` Objective C lifetime qualifiers. We decorate these by creating an artificial template type `Autoreleasing`, `Strong`, or `Weak` in the `__ObjC` namespace. These are only considered in the template type specialization and not the function parameter. llvm-svn: 324701
2018-02-09 11:23:54 +08:00
switch (Quals.getObjCLifetime()) {
case Qualifiers::OCL_None:
case Qualifiers::OCL_ExplicitNone:
break;
case Qualifiers::OCL_Autoreleasing:
case Qualifiers::OCL_Strong:
case Qualifiers::OCL_Weak:
return mangleObjCLifetime(PointeeType, Quals, 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
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
}
// <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();
[MS ABI] Replace dead code with an assertion As per C++ [dcl.ref]p1, cv-qualified references are not valid. As such, change the mangler to assert that this event does not happen. llvm-svn: 256662
2015-12-31 13:36:50 +08:00
assert(!Quals.hasConst() && !Quals.hasVolatile() && "unexpected qualifier!");
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
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();
[MS ABI] Replace dead code with an assertion As per C++ [dcl.ref]p1, cv-qualified references are not valid. As such, change the mangler to assert that this event does not happen. llvm-svn: 256662
2015-12-31 13:36:50 +08:00
assert(!Quals.hasConst() && !Quals.hasVolatile() && "unexpected qualifier!");
Out << "$$Q";
[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);
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) {
[MS ABI] Add a mangling for _Complex MSVC doesn't implement a mangling for C99's _Complex so we must invent our own. For now, treating it like a class type called _Complex in the __clang namespace. This means that 'void f(__Complex int))' will demangle as: 'void f(struct __clang::_Complex<int>)' llvm-svn: 256583
2015-12-30 06:02:15 +08:00
QualType ElementType = T->getElementType();
llvm::SmallString<64> TemplateMangling;
llvm::raw_svector_ostream Stream(TemplateMangling);
MicrosoftCXXNameMangler Extra(Context, Stream);
Stream << "?$";
Extra.mangleSourceName("_Complex");
Extra.mangleType(ElementType, Range, QMM_Escape);
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, TemplateMangling, {"__clang"});
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
}
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
// Returns true for types that mangleArtificialTagType() gets called for with
[ms] Fix mangling of vector types in QMM_Result contexts. If QMM_Result is set (which it is for return types, RTTI descriptors, and exception type descriptors), tag types (structs, enums, classes, unions) get their qualifiers mangled in. __m64 and friends is a struct/union thingy in MSVC, but not in clang's headers. To make mangling work, we call mangleArtificalTagType(TTK_Union/TTK_Struct for the vector types to mangle them as tag types -- but the isa<TagType> check when mangling in QMM_Result mode isn't true for these vector types. Add an isArtificialTagType() function and check for that too. Fixes PR37276 and some other issues. I tried to audit all references to TagDecl and TagType in MicrosoftMangle.cpp to find other places where we need to call mangleArtificalTagType(), but couldn't find any. I tried to audit all calls to mangleArtificalTagType() to see if isArtificialTagType() needs to handle more than just the vector types, but as far as I can tell all other types we use it for are types that MSVC can't handle at all (Objective-C types etc). https://reviews.llvm.org/D49597 llvm-svn: 337732
2018-07-24 04:04:00 +08:00
// TTK_Union, TTK_Struct, TTK_Class and where compatibility with MSVC's
// mangling matters.
// (It doesn't matter for Objective-C types and the like that cl.exe doesn't
// support.)
bool MicrosoftCXXNameMangler::isArtificialTagType(QualType T) const {
const Type *ty = T.getTypePtr();
switch (ty->getTypeClass()) {
default:
return false;
case Type::Vector: {
// For ABI compatibility only __m64, __m128(id), and __m256(id) matter,
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
// but since mangleType(VectorType*) always calls mangleArtificialTagType()
[ms] Fix mangling of vector types in QMM_Result contexts. If QMM_Result is set (which it is for return types, RTTI descriptors, and exception type descriptors), tag types (structs, enums, classes, unions) get their qualifiers mangled in. __m64 and friends is a struct/union thingy in MSVC, but not in clang's headers. To make mangling work, we call mangleArtificalTagType(TTK_Union/TTK_Struct for the vector types to mangle them as tag types -- but the isa<TagType> check when mangling in QMM_Result mode isn't true for these vector types. Add an isArtificialTagType() function and check for that too. Fixes PR37276 and some other issues. I tried to audit all references to TagDecl and TagType in MicrosoftMangle.cpp to find other places where we need to call mangleArtificalTagType(), but couldn't find any. I tried to audit all calls to mangleArtificalTagType() to see if isArtificialTagType() needs to handle more than just the vector types, but as far as I can tell all other types we use it for are types that MSVC can't handle at all (Objective-C types etc). https://reviews.llvm.org/D49597 llvm-svn: 337732
2018-07-24 04:04:00 +08:00
// just always return true (the other vector types are clang-only).
return true;
}
}
}
[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] Cleanup our mangling of vector types We used to produce a type which demangled to: union __clang_vec8_F That 'F' is the mangling for 'short' but it is present in the mangled name in an inappropriate place, leading to it not getting demangled. Instead, create a synthetic class type in a synthetic namespace called __clang. With this, it now demangles to: union __clang::__vector<short,8> llvm-svn: 256556
2015-12-29 19:45:58 +08:00
size_t OutSizeBefore = Out.tell();
AST: extend MS decoration handling for extended vectors We correctly handled extended vectors of non-floating point types. However, we have the Intel style builtins which MSVC also supports which do overlap in sizes with the floating point extended vectors. This would result in overloading of floating point extended vector types which matched sizes (e.g. <3 x float> would be backed by a <4 x float> and thus match sizes) to be mangled similarly. Extended vectors are a clang extension which live outside of the builtins, so mangle them all similarly. This change just extends the current scheme to treat floating point types similar to the way that we treat other types currently. This now allows the swift runtime to be built for Windows again. llvm-svn: 345479
2018-10-29 02:05:20 +08:00
if (!isa<ExtVectorType>(T)) {
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) {
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Union, "__m64");
AST: extend MS decoration handling for extended vectors We correctly handled extended vectors of non-floating point types. However, we have the Intel style builtins which MSVC also supports which do overlap in sizes with the floating point extended vectors. This would result in overloading of floating point extended vector types which matched sizes (e.g. <3 x float> would be backed by a <4 x float> and thus match sizes) to be mangled similarly. Extended vectors are a clang extension which live outside of the builtins, so mangle them all similarly. This change just extends the current scheme to treat floating point types similar to the way that we treat other types currently. This now allows the swift runtime to be built for Windows again. llvm-svn: 345479
2018-10-29 02:05:20 +08:00
} else if (Width >= 128) {
if (ET->getKind() == BuiltinType::Float)
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Union, "__m" + llvm::utostr(Width));
AST: extend MS decoration handling for extended vectors We correctly handled extended vectors of non-floating point types. However, we have the Intel style builtins which MSVC also supports which do overlap in sizes with the floating point extended vectors. This would result in overloading of floating point extended vector types which matched sizes (e.g. <3 x float> would be backed by a <4 x float> and thus match sizes) to be mangled similarly. Extended vectors are a clang extension which live outside of the builtins, so mangle them all similarly. This change just extends the current scheme to treat floating point types similar to the way that we treat other types currently. This now allows the swift runtime to be built for Windows again. llvm-svn: 345479
2018-10-29 02:05:20 +08:00
else if (ET->getKind() == BuiltinType::LongLong)
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Union, "__m" + llvm::utostr(Width) + 'i');
AST: extend MS decoration handling for extended vectors We correctly handled extended vectors of non-floating point types. However, we have the Intel style builtins which MSVC also supports which do overlap in sizes with the floating point extended vectors. This would result in overloading of floating point extended vector types which matched sizes (e.g. <3 x float> would be backed by a <4 x float> and thus match sizes) to be mangled similarly. Extended vectors are a clang extension which live outside of the builtins, so mangle them all similarly. This change just extends the current scheme to treat floating point types similar to the way that we treat other types currently. This now allows the swift runtime to be built for Windows again. llvm-svn: 345479
2018-10-29 02:05:20 +08:00
else if (ET->getKind() == BuiltinType::Double)
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, "__m" + llvm::utostr(Width) + 'd');
AST: extend MS decoration handling for extended vectors We correctly handled extended vectors of non-floating point types. However, we have the Intel style builtins which MSVC also supports which do overlap in sizes with the floating point extended vectors. This would result in overloading of floating point extended vector types which matched sizes (e.g. <3 x float> would be backed by a <4 x float> and thus match sizes) to be mangled similarly. Extended vectors are a clang extension which live outside of the builtins, so mangle them all similarly. This change just extends the current scheme to treat floating point types similar to the way that we treat other types currently. This now allows the swift runtime to be built for Windows again. llvm-svn: 345479
2018-10-29 02:05:20 +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
}
[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] Cleanup our mangling of vector types We used to produce a type which demangled to: union __clang_vec8_F That 'F' is the mangling for 'short' but it is present in the mangled name in an inappropriate place, leading to it not getting demangled. Instead, create a synthetic class type in a synthetic namespace called __clang. With this, it now demangles to: union __clang::__vector<short,8> llvm-svn: 256556
2015-12-29 19:45:58 +08:00
bool IsBuiltin = Out.tell() != OutSizeBefore;
[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.
[MS ABI] Cleanup our mangling of vector types We used to produce a type which demangled to: union __clang_vec8_F That 'F' is the mangling for 'short' but it is present in the mangled name in an inappropriate place, leading to it not getting demangled. Instead, create a synthetic class type in a synthetic namespace called __clang. With this, it now demangles to: union __clang::__vector<short,8> llvm-svn: 256556
2015-12-29 19:45:58 +08:00
llvm::SmallString<64> TemplateMangling;
llvm::raw_svector_ostream Stream(TemplateMangling);
MicrosoftCXXNameMangler Extra(Context, Stream);
Stream << "?$";
Extra.mangleSourceName("__vector");
Extra.mangleType(QualType(ET, 0), Range, QMM_Escape);
Extra.mangleIntegerLiteral(llvm::APSInt::getUnsigned(T->getNumElements()),
/*IsBoolean=*/false);
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Union, TemplateMangling, {"__clang"});
[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
}
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
}
PR15730/PR16986 Allow dependently typed vector_size types. As listed in the above PRs, vector_size doesn't allow dependent types/values. This patch introduces a new DependentVectorType to handle a VectorType that has a dependent size or type. In the future, ALL the vector-types should be able to create one of these to handle dependent types/sizes as well. For example, DependentSizedExtVectorType could likely be switched to just use this instead, though that is left as an exercise for the future. Differential Revision: https://reviews.llvm.org/D49045 llvm-svn: 337036
2018-07-14 03:46:04 +08:00
void MicrosoftCXXNameMangler::mangleType(const DependentVectorType *T,
Qualifiers, SourceRange Range) {
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(
DiagnosticsEngine::Error,
"cannot mangle this dependent-sized vector type yet");
Diags.Report(Range.getBegin(), DiagID) << 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;
}
Dependent Address Space Support This patch relates to: https://reviews.llvm.org/D33666 This adds support for template parameters to be passed to the address_space attribute. The main goal is to add further flexibility to the attribute and allow for it to be used easily with templates. The main additions are a new type (DependentAddressSpaceType) alongside its TypeLoc and its mangling. As well as the logic required to support dependent address spaces which mainly resides in TreeTransform.h and SemaType.cpp. llvm-svn: 314649
2017-10-02 14:25:51 +08:00
void MicrosoftCXXNameMangler::mangleType(const DependentAddressSpaceType *T,
Qualifiers, SourceRange Range) {
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(
DiagnosticsEngine::Error,
"cannot mangle this dependent address space 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) {
[AST] Revert mangling changes from r339428 As discussed in https://reviews.llvm.org/D50144, we want Obj-C classes to have the same mangling as C++ structs, to support headers like the following: ``` @class I; struct I; void f(I *); ``` since the header can be used from both C++ and Obj-C++ TUs, and we want a consistent mangling across the two to prevent link errors. Itanium mangles both the same way, and so should the MS ABI. The main concern with having the same mangling for C++ structs and Obj-C classes was that we want to treat them differently for the purposes of exception handling, e.g. we don't want a C++ catch statement for a struct to be able to catch an Obj-C class with the same name as the struct. We can accomplish this by mangling Obj-C class names differently in their RTTI, which I'll do in a follow-up patch. Differential Revision: https://reviews.llvm.org/D52581 llvm-svn: 343808
2018-10-05 03:50:14 +08:00
// ObjC interfaces have structs underlying them.
[MS ABI] Cleanup the mangling of artifical types Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
2015-12-29 19:45:53 +08:00
mangleTagTypeKind(TTK_Struct);
[AST] Revert mangling changes from r339428 As discussed in https://reviews.llvm.org/D50144, we want Obj-C classes to have the same mangling as C++ structs, to support headers like the following: ``` @class I; struct I; void f(I *); ``` since the header can be used from both C++ and Obj-C++ TUs, and we want a consistent mangling across the two to prevent link errors. Itanium mangles both the same way, and so should the MS ABI. The main concern with having the same mangling for C++ structs and Obj-C classes was that we want to treat them differently for the purposes of exception handling, e.g. we don't want a C++ catch statement for a struct to be able to catch an Obj-C class with the same name as the struct. We can accomplish this by mangling Obj-C class names differently in their RTTI, which I'll do in a follow-up patch. Differential Revision: https://reviews.llvm.org/D52581 llvm-svn: 343808
2018-10-05 03:50:14 +08:00
mangleName(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
}
AST: add missing ObjC extensions to MS style name decoration Add support for encoding type arguments for lightweight generics in Objective-C++ mode. Additionally, add support for the `__kindof` modifier. This should complete the coverage of the ObjC extensions that clang currently supports under the MS style name decoration scheme. This is implemented similar to the Objective-C lifetime qualifiers decoration: a template specialization in the `__ObjC` namespace so that we can interoperate with Microsoft's tools as well as ensure that we do not accidentally collide with new features in the Microsoft implementation. Since the `__kindof` appertains to the type and not the pointer, we apply the template specialization to the underlying type instead of the pointer type. Unfortunately, until D52581 is resolved, the generated name is not really compatible with the MS tools as well as breaks interoperability with Objective-C++ and C++. This resolves PR37754! llvm-svn: 343338
2018-09-29 00:47:53 +08:00
void MicrosoftCXXNameMangler::mangleType(const ObjCObjectType *T,
Qualifiers Quals, SourceRange Range) {
if (T->isKindOfType())
return mangleObjCKindOfType(T, Quals, Range);
if (T->qual_empty() && !T->isSpecialized())
AST: support protocol conformances on id/class/interfaces in MS ABI Add support for mangling ObjC protocol conformances in MS ABI as if they are COM interfaces. By diverging from the itanium mangling of `objc_protocol` prefixed names, this approach allows for a semi-reasonable, albeit of questionable sanity, undecoration via existing tooling. There is also the possibility of adding an extension and taking part of the namespace to add the conformance via the `L` and `Z` "modifiers", but the existing tooling would not be able to properly undecorated the symbol even though incidentally `undname` currently produces something legible while wine's implementation is not able to cope with the extension. This allows for the disambiguation of overloads where the parameter differs only in the protocol conformance of the ObjC type, e.g. ``` @protocol P; void f(std::vector<id>); void f(std::vector<id<P>>); ``` which clang would previously fail due to the mangling being identical as the protocol conformance was ignored. llvm-svn: 323547
2018-01-27 03:08:26 +08:00
return mangleType(T->getBaseType(), Range, QMM_Drop);
ArgBackRefMap OuterArgsContext;
BackRefVec OuterTemplateContext;
TypeBackReferences.swap(OuterArgsContext);
NameBackReferences.swap(OuterTemplateContext);
mangleTagTypeKind(TTK_Struct);
Out << "?$";
if (T->isObjCId())
[AST] Revert mangling changes from r339428 As discussed in https://reviews.llvm.org/D50144, we want Obj-C classes to have the same mangling as C++ structs, to support headers like the following: ``` @class I; struct I; void f(I *); ``` since the header can be used from both C++ and Obj-C++ TUs, and we want a consistent mangling across the two to prevent link errors. Itanium mangles both the same way, and so should the MS ABI. The main concern with having the same mangling for C++ structs and Obj-C classes was that we want to treat them differently for the purposes of exception handling, e.g. we don't want a C++ catch statement for a struct to be able to catch an Obj-C class with the same name as the struct. We can accomplish this by mangling Obj-C class names differently in their RTTI, which I'll do in a follow-up patch. Differential Revision: https://reviews.llvm.org/D52581 llvm-svn: 343808
2018-10-05 03:50:14 +08:00
mangleSourceName("objc_object");
AST: support protocol conformances on id/class/interfaces in MS ABI Add support for mangling ObjC protocol conformances in MS ABI as if they are COM interfaces. By diverging from the itanium mangling of `objc_protocol` prefixed names, this approach allows for a semi-reasonable, albeit of questionable sanity, undecoration via existing tooling. There is also the possibility of adding an extension and taking part of the namespace to add the conformance via the `L` and `Z` "modifiers", but the existing tooling would not be able to properly undecorated the symbol even though incidentally `undname` currently produces something legible while wine's implementation is not able to cope with the extension. This allows for the disambiguation of overloads where the parameter differs only in the protocol conformance of the ObjC type, e.g. ``` @protocol P; void f(std::vector<id>); void f(std::vector<id<P>>); ``` which clang would previously fail due to the mangling being identical as the protocol conformance was ignored. llvm-svn: 323547
2018-01-27 03:08:26 +08:00
else if (T->isObjCClass())
[AST] Revert mangling changes from r339428 As discussed in https://reviews.llvm.org/D50144, we want Obj-C classes to have the same mangling as C++ structs, to support headers like the following: ``` @class I; struct I; void f(I *); ``` since the header can be used from both C++ and Obj-C++ TUs, and we want a consistent mangling across the two to prevent link errors. Itanium mangles both the same way, and so should the MS ABI. The main concern with having the same mangling for C++ structs and Obj-C classes was that we want to treat them differently for the purposes of exception handling, e.g. we don't want a C++ catch statement for a struct to be able to catch an Obj-C class with the same name as the struct. We can accomplish this by mangling Obj-C class names differently in their RTTI, which I'll do in a follow-up patch. Differential Revision: https://reviews.llvm.org/D52581 llvm-svn: 343808
2018-10-05 03:50:14 +08:00
mangleSourceName("objc_class");
AST: support protocol conformances on id/class/interfaces in MS ABI Add support for mangling ObjC protocol conformances in MS ABI as if they are COM interfaces. By diverging from the itanium mangling of `objc_protocol` prefixed names, this approach allows for a semi-reasonable, albeit of questionable sanity, undecoration via existing tooling. There is also the possibility of adding an extension and taking part of the namespace to add the conformance via the `L` and `Z` "modifiers", but the existing tooling would not be able to properly undecorated the symbol even though incidentally `undname` currently produces something legible while wine's implementation is not able to cope with the extension. This allows for the disambiguation of overloads where the parameter differs only in the protocol conformance of the ObjC type, e.g. ``` @protocol P; void f(std::vector<id>); void f(std::vector<id<P>>); ``` which clang would previously fail due to the mangling being identical as the protocol conformance was ignored. llvm-svn: 323547
2018-01-27 03:08:26 +08:00
else
[AST] Revert mangling changes from r339428 As discussed in https://reviews.llvm.org/D50144, we want Obj-C classes to have the same mangling as C++ structs, to support headers like the following: ``` @class I; struct I; void f(I *); ``` since the header can be used from both C++ and Obj-C++ TUs, and we want a consistent mangling across the two to prevent link errors. Itanium mangles both the same way, and so should the MS ABI. The main concern with having the same mangling for C++ structs and Obj-C classes was that we want to treat them differently for the purposes of exception handling, e.g. we don't want a C++ catch statement for a struct to be able to catch an Obj-C class with the same name as the struct. We can accomplish this by mangling Obj-C class names differently in their RTTI, which I'll do in a follow-up patch. Differential Revision: https://reviews.llvm.org/D52581 llvm-svn: 343808
2018-10-05 03:50:14 +08:00
mangleSourceName(T->getInterface()->getName());
AST: support protocol conformances on id/class/interfaces in MS ABI Add support for mangling ObjC protocol conformances in MS ABI as if they are COM interfaces. By diverging from the itanium mangling of `objc_protocol` prefixed names, this approach allows for a semi-reasonable, albeit of questionable sanity, undecoration via existing tooling. There is also the possibility of adding an extension and taking part of the namespace to add the conformance via the `L` and `Z` "modifiers", but the existing tooling would not be able to properly undecorated the symbol even though incidentally `undname` currently produces something legible while wine's implementation is not able to cope with the extension. This allows for the disambiguation of overloads where the parameter differs only in the protocol conformance of the ObjC type, e.g. ``` @protocol P; void f(std::vector<id>); void f(std::vector<id<P>>); ``` which clang would previously fail due to the mangling being identical as the protocol conformance was ignored. llvm-svn: 323547
2018-01-27 03:08:26 +08:00
AST: support ObjC lifetime qualifiers in MS ABI Adjust the ObjC protocol conformance workaround to be more extensible. Use a synthetic type for the protocol (`struct Protocol`). Embed this within a reserved namespace to permit extending the extended pointer type qualifiers similarly for ObjC lifetime qualifiers. Introduce additional special handling for `__autoreleasing`, `__strong`, and `__weak` Objective C lifetime qualifiers. We decorate these by creating an artificial template type `Autoreleasing`, `Strong`, or `Weak` in the `__ObjC` namespace. These are only considered in the template type specialization and not the function parameter. llvm-svn: 324701
2018-02-09 11:23:54 +08:00
for (const auto &Q : T->quals())
mangleObjCProtocol(Q);
AST: add missing ObjC extensions to MS style name decoration Add support for encoding type arguments for lightweight generics in Objective-C++ mode. Additionally, add support for the `__kindof` modifier. This should complete the coverage of the ObjC extensions that clang currently supports under the MS style name decoration scheme. This is implemented similar to the Objective-C lifetime qualifiers decoration: a template specialization in the `__ObjC` namespace so that we can interoperate with Microsoft's tools as well as ensure that we do not accidentally collide with new features in the Microsoft implementation. Since the `__kindof` appertains to the type and not the pointer, we apply the template specialization to the underlying type instead of the pointer type. Unfortunately, until D52581 is resolved, the generated name is not really compatible with the MS tools as well as breaks interoperability with Objective-C++ and C++. This resolves PR37754! llvm-svn: 343338
2018-09-29 00:47:53 +08:00
if (T->isSpecialized())
for (const auto &TA : T->getTypeArgs())
mangleType(TA, Range, QMM_Drop);
AST: support protocol conformances on id/class/interfaces in MS ABI Add support for mangling ObjC protocol conformances in MS ABI as if they are COM interfaces. By diverging from the itanium mangling of `objc_protocol` prefixed names, this approach allows for a semi-reasonable, albeit of questionable sanity, undecoration via existing tooling. There is also the possibility of adding an extension and taking part of the namespace to add the conformance via the `L` and `Z` "modifiers", but the existing tooling would not be able to properly undecorated the symbol even though incidentally `undname` currently produces something legible while wine's implementation is not able to cope with the extension. This allows for the disambiguation of overloads where the parameter differs only in the protocol conformance of the ObjC type, e.g. ``` @protocol P; void f(std::vector<id>); void f(std::vector<id<P>>); ``` which clang would previously fail due to the mangling being identical as the protocol conformance was ignored. llvm-svn: 323547
2018-01-27 03:08:26 +08:00
Out << '@';
Out << '@';
TypeBackReferences.swap(OuterArgsContext);
NameBackReferences.swap(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
}
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;
}
PR0091R3: Implement parsing support for using templates as types. This change adds a new type node, DeducedTemplateSpecializationType, to represent a type template name that has been used as a type. This is modeled around AutoType, and shares a common base class for representing a deduced placeholder type. We allow deduced class template types in a few more places than the standard does: in conditions and for-range-declarators, and in new-type-ids. This is consistent with GCC and with discussion on the core reflector. This patch does not yet support deduced class template types being named in typename specifiers. llvm-svn: 293207
2017-01-27 04:40:47 +08:00
void MicrosoftCXXNameMangler::mangleType(
const DeducedTemplateSpecializationType *T, Qualifiers, SourceRange Range) {
assert(T->getDeducedType().isNull() && "expecting a dependent type!");
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this deduced class 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 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) {
[MS ABI] Implement a mangling for _Atomic types MSVC doesn't implement a mangling for C11's _Atomic so we must invent our own. For now, treating it like a class type called _Atomic in the __clang namespace. This means that 'void f(__Atomic(int))' will demangle as: 'void f(struct __clang::_Atomic<int>)' llvm-svn: 256557
2015-12-29 19:46:00 +08:00
QualType ValueType = T->getValueType();
llvm::SmallString<64> TemplateMangling;
llvm::raw_svector_ostream Stream(TemplateMangling);
MicrosoftCXXNameMangler Extra(Context, Stream);
Stream << "?$";
Extra.mangleSourceName("_Atomic");
Extra.mangleType(ValueType, Range, QMM_Escape);
[AST] Fix typo in MicrosoftMangle Correct the spelling from Artifical to Artificial. Differential Revision: https://reviews.llvm.org/D54536 llvm-svn: 346882
2018-11-15 03:16:22 +08:00
mangleArtificialTagType(TTK_Struct, TemplateMangling, {"__clang"});
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
}
[OpenCL] Pipe type support Summary: Support for OpenCL 2.0 pipe type. This is a bug-fix version for bader's patch reviews.llvm.org/D14441 Reviewers: pekka.jaaskelainen, Anastasia Subscribers: bader, Anastasia, cfe-commits Differential Revision: http://reviews.llvm.org/D15603 llvm-svn: 257254
2016-01-09 20:53:17 +08:00
void MicrosoftCXXNameMangler::mangleType(const PipeType *T, Qualifiers,
SourceRange Range) {
DiagnosticsEngine &Diags = Context.getDiags();
unsigned DiagID = Diags.getCustomDiagID(DiagnosticsEngine::Error,
"cannot mangle this OpenCL pipe 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");
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
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 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>
[MS] Mangle return adjusting thunks with the public access specifier MSVC does this, so we should too. Fixes PR40138 llvm-svn: 350071
2018-12-27 04:07:52 +08:00
static void mangleThunkThisAdjustment(AccessSpecifier AS,
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 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;
[MS] Mangle return adjusting thunks with the public access specifier MSVC does this, so we should too. Fixes PR40138 llvm-svn: 350071
2018-12-27 04:07:52 +08:00
switch (AS) {
Fix PR17738 - add support for vtordisp thunks when using -cxx-abi microsoft llvm-svn: 194132
2013-11-06 14:24:31 +08:00
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) {
[MS] Mangle return adjusting thunks with the public access specifier MSVC does this, so we should too. Fixes PR40138 llvm-svn: 350071
2018-12-27 04:07:52 +08:00
switch (AS) {
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");
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 {
[MS] Mangle return adjusting thunks with the public access specifier MSVC does this, so we should too. Fixes PR40138 llvm-svn: 350071
2018-12-27 04:07:52 +08:00
switch (AS) {
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");
case AS_private:
Out << 'A';
break;
case AS_protected:
Out << 'I';
break;
case AS_public:
Out << 'Q';
}
}
}
Fix some DenseMap use-after-rehash bugs and hoist MethodVFTableLocation This re-lands r328845 with fixes for crbug.com/827810. The initial motiviation was to hoist MethodVFTableLocation to global scope so it could be forward declared. In this patch, I noticed that MicrosoftVTableContext uses some risky patterns. It has methods that return references to data stored in DenseMaps. I've made some of them return by value for trivial structs and I've moved some things into separate allocations. llvm-svn: 329007
2018-04-03 04:00:39 +08:00
void MicrosoftMangleContextImpl::mangleVirtualMemPtrThunk(
const CXXMethodDecl *MD, const MethodVFTableLocation &ML,
raw_ostream &Out) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << '?';
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.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) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << '?';
Add MicrosoftVFTableContext to AST llvm-svn: 187409
2013-07-30 17:46:19 +08:00
Mangler.mangleName(MD);
[MS] Mangle return adjusting thunks with the public access specifier MSVC does this, so we should too. Fixes PR40138 llvm-svn: 350071
2018-12-27 04:07:52 +08:00
// Usually the thunk uses the access specifier of the new method, but if this
// is a covariant return thunk, then MSVC always uses the public access
// specifier, and we do the same.
AccessSpecifier AS = Thunk.Return.isEmpty() ? MD->getAccess() : AS_public;
mangleThunkThisAdjustment(AS, Thunk.This, Mangler, MHO);
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
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);
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO, DD, Type);
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "??_E";
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
Mangler.mangleName(DD->getParent());
[MS] Mangle return adjusting thunks with the public access specifier MSVC does this, so we should too. Fixes PR40138 llvm-svn: 350071
2018-12-27 04:07:52 +08:00
mangleThunkThisAdjustment(DD->getAccess(), Adjustment, Mangler, MHO);
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
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.
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
Revert "Revert r260388 "[MS ABI] Never reference dllimport'd vtables"" This reverts commit r260449. We would supress our emission of vftable definitions if we thought another translation unit would provide the definition because we saw an explicit instantiation declaration. This is not the case with dllimport, we want to synthesize a definition of the vftable regardless. This fixes PR26569. llvm-svn: 260548
2016-02-12 01:49:28 +08:00
if (Derived->hasAttr<DLLImportAttr>())
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "??_S";
Revert "Revert r260388 "[MS ABI] Never reference dllimport'd vtables"" This reverts commit r260449. We would supress our emission of vftable definitions if we thought another translation unit would provide the definition because we saw an explicit instantiation declaration. This is not the case with dllimport, we want to synthesize a definition of the vftable regardless. This fixes PR26569. llvm-svn: 260548
2016-02-12 01:49:28 +08:00
else
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "??_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.
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "??_8";
[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.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) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "??_R0";
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
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 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) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "??_K";
[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
Mangler.mangleName(SrcRD);
Mangler.getStream() << "$C";
Mangler.mangleName(DstRD);
}
[MS ABI] Support throwing/catching __unaligned types We need to mark the appropriate bits in ThrowInfo and HandlerType so that the personality routine can correctly handle qualification conversions. llvm-svn: 275154
2016-07-12 12:42:50 +08:00
void MicrosoftMangleContextImpl::mangleCXXThrowInfo(QualType T, bool IsConst,
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
bool IsVolatile,
[MS ABI] Support throwing/catching __unaligned types We need to mark the appropriate bits in ThrowInfo and HandlerType so that the personality routine can correctly handle qualification conversions. llvm-svn: 275154
2016-07-12 12:42:50 +08:00
bool IsUnaligned,
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
uint32_t NumEntries,
raw_ostream &Out) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
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() << "_TI";
if (IsConst)
Mangler.getStream() << 'C';
if (IsVolatile)
Mangler.getStream() << 'V';
[MS ABI] Support throwing/catching __unaligned types We need to mark the appropriate bits in ThrowInfo and HandlerType so that the personality routine can correctly handle qualification conversions. llvm-svn: 275154
2016-07-12 12:42:50 +08:00
if (IsUnaligned)
Mangler.getStream() << 'U';
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() << NumEntries;
Mangler.mangleType(T, SourceRange(), MicrosoftCXXNameMangler::QMM_Result);
}
void MicrosoftMangleContextImpl::mangleCXXCatchableTypeArray(
QualType T, uint32_t NumEntries, raw_ostream &Out) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
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() << "_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);
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Stream);
mangleCXXRTTI(T, MHO);
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
}
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << RTTIMangling;
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
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.
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;
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
if (!getASTContext().getLangOpts().isCompatibleWithMSVC(
LangOptions::MSVC2015) &&
CD) {
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::raw_svector_ostream Stream(CopyCtorMangling);
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Stream);
mangleCXXCtor(CD, CT, MHO);
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
}
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << CopyCtorMangling;
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
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] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "??_R1";
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
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) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "??_R2";
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
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) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "??_R3";
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
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] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
llvm::SmallString<64> VFTableMangling;
llvm::raw_svector_ostream Stream(VFTableMangling);
mangleCXXVFTable(Derived, BasePath, Stream);
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
if (VFTableMangling.startswith("??@")) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
assert(VFTableMangling.endswith("@"));
Out << VFTableMangling << "??_R4@";
return;
}
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
assert(VFTableMangling.startswith("??_7") ||
VFTableMangling.startswith("??_S"));
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Out << "??_R4" << StringRef(VFTableMangling).drop_front(4);
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) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
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
// 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
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "?filt$" << SEHFilterIds[EnclosingDecl]++ << "@0@";
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
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) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
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
// 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
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "?fin$" << SEHFinallyIds[EnclosingDecl]++ << "@0@";
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
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] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler mangler(*this, MHO, 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) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler mangler(*this, MHO, 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
[MS ABI] Invent a mangling for reference temporaries MSVC is non-conforming and doesn't have a mangling for these. Invent our own to unblock folks using clang. This fixes PR25795. llvm-svn: 256589
2015-12-30 06:25:14 +08:00
void MicrosoftMangleContextImpl::mangleReferenceTemporary(
const VarDecl *VD, unsigned ManglingNumber, raw_ostream &Out) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
[MS ABI] Invent a mangling for reference temporaries MSVC is non-conforming and doesn't have a mangling for these. Invent our own to unblock folks using clang. This fixes PR25795. llvm-svn: 256589
2015-12-30 06:25:14 +08:00
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "?$RT" << ManglingNumber << '@';
[MS ABI] Invent a mangling for reference temporaries MSVC is non-conforming and doesn't have a mangling for these. Invent our own to unblock folks using clang. This fixes PR25795. llvm-svn: 256589
2015-12-30 06:25:14 +08:00
Mangler.mangle(VD, "");
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) {
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
[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
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "?$TSS" << GuardNum << '@';
[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
Mangler.mangleNestedName(VD);
[MSVC2015] Fix mangling for static variables initialization guards It seems that suffix '@4HA' was omitted for unknown reason. It is non-cont non-volatile 'int' type of normal variable TSS. Differential revision: http://reviews.llvm.org/D20683 llvm-svn: 270974
2016-05-27 16:52:34 +08:00
Mangler.getStream() << "@4HA";
[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
}
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.
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
[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
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] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << (VD->getTLSKind() ? "??__J" : "??_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 {
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "?$S1@";
[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
}
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,
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
char CharCode,
raw_ostream &Out) {
msvc_hashing_ostream MHO(Out);
MicrosoftCXXNameMangler Mangler(*this, MHO);
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "??__" << CharCode;
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()) {
[MS ABI] Fix mangling issue with dynamic initializer stubs. There are two types of dynamic initializer stubs. There's `dynamic initializer for 'x''(void) and `dynamic initializer for `static Foo::Bar StaticDataMember''(void) The second case is disambiguated from the first by the presence of a ? after the operator code. So the first will appear something like ?__E<name> while the second will appear something like ?__E?<name>. clang-cl was mangling these both the same though. This patch matches behavior with cl. Differential Revision: https://reviews.llvm.org/D51500 llvm-svn: 341117
2018-08-31 04:53:11 +08:00
Mangler.getStream() << '?';
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
Mangler.mangleVariableEncoding(D);
[MS ABI] Fix mangling issue with dynamic initializer stubs. There are two types of dynamic initializer stubs. There's `dynamic initializer for 'x''(void) and `dynamic initializer for `static Foo::Bar StaticDataMember''(void) The second case is disambiguated from the first by the presence of a ? after the operator code. So the first will appear something like ?__E<name> while the second will appear something like ?__E?<name>. clang-cl was mangling these both the same though. This patch matches behavior with cl. Differential Revision: https://reviews.llvm.org/D51500 llvm-svn: 341117
2018-08-31 04:53:11 +08:00
Mangler.getStream() << "@@";
} else {
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
}
[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
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
mangleInitFiniStub(D, 'E', 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
}
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
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
mangleInitFiniStub(D, 'F', 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
}
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) {
[ms] Fix mangling of char16_t and char32_t to be compatible with MSVC. MSVC limits char16_t and char32_t string literal names to 32 bytes of character data, not to 32 characters. wchar_t string literal names on the other hand can get up to 64 bytes of character data. https://reviews.llvm.org/D48781 llvm-svn: 336097
2018-07-02 20:31:20 +08:00
// <char-type> ::= 0 # char, char16_t, char32_t
// # (little endian char data in mangling)
// ::= 1 # wchar_t (big endian char data in mangling)
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> ::= <non-negative integer> # the length of the literal
//
// <encoded-crc> ::= <hex digit>+ @ # crc of the literal including
[ms] Fix mangling of string literals used to initialize arrays larger or smaller than the literal A Chromium developer reported a bug which turned out to be a mangling collision between these two literals: char s[] = "foo"; char t[32] = "foo"; They may look the same, but for the initialization of t we will (under some circumstances) use a literal that's extended with zeros, and both the length and those zeros should be accounted for by the mangling. This actually makes the mangling code simpler: where it previously had special logic for null terminators, which are not part of the StringLiteral, that is now covered by the general algorithm. (The problem was reported at https://crbug.com/857442) Differential Revision: https://reviews.llvm.org/D48928 llvm-svn: 336415
2018-07-06 14:54:16 +08:00
// # trailing null bytes
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-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);
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
Mangler.getStream() << "??_C@_";
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] Fix mangling of string literals used to initialize arrays larger or smaller than the literal A Chromium developer reported a bug which turned out to be a mangling collision between these two literals: char s[] = "foo"; char t[32] = "foo"; They may look the same, but for the initialization of t we will (under some circumstances) use a literal that's extended with zeros, and both the length and those zeros should be accounted for by the mangling. This actually makes the mangling code simpler: where it previously had special logic for null terminators, which are not part of the StringLiteral, that is now covered by the general algorithm. (The problem was reported at https://crbug.com/857442) Differential Revision: https://reviews.llvm.org/D48928 llvm-svn: 336415
2018-07-06 14:54:16 +08:00
// The actual string length might be different from that of the string literal
// in cases like:
// char foo[3] = "foobar";
// char bar[42] = "foobar";
// Where it is truncated or zero-padded to fit the array. This is the length
// used for mangling, and any trailing null-bytes also need to be mangled.
unsigned StringLength = getASTContext()
.getAsConstantArrayType(SL->getType())
->getSize()
.getZExtValue();
unsigned StringByteLength = StringLength * SL->getCharByteWidth();
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
// <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
[ms] Fix mangling of string literals used to initialize arrays larger or smaller than the literal A Chromium developer reported a bug which turned out to be a mangling collision between these two literals: char s[] = "foo"; char t[32] = "foo"; They may look the same, but for the initialization of t we will (under some circumstances) use a literal that's extended with zeros, and both the length and those zeros should be accounted for by the mangling. This actually makes the mangling code simpler: where it previously had special logic for null terminators, which are not part of the StringLiteral, that is now covered by the general algorithm. (The problem was reported at https://crbug.com/857442) Differential Revision: https://reviews.llvm.org/D48928 llvm-svn: 336415
2018-07-06 14:54:16 +08:00
// of the string in bytes.
Mangler.mangleNumber(StringByteLength);
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
Remove unused lambda captures. NFC llvm-svn: 291939
2017-01-14 02:55:32 +08:00
auto GetLittleEndianByte = [&SL](unsigned Index) {
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
unsigned CharByteWidth = SL->getCharByteWidth();
[ms] Fix mangling of string literals used to initialize arrays larger or smaller than the literal A Chromium developer reported a bug which turned out to be a mangling collision between these two literals: char s[] = "foo"; char t[32] = "foo"; They may look the same, but for the initialization of t we will (under some circumstances) use a literal that's extended with zeros, and both the length and those zeros should be accounted for by the mangling. This actually makes the mangling code simpler: where it previously had special logic for null terminators, which are not part of the StringLiteral, that is now covered by the general algorithm. (The problem was reported at https://crbug.com/857442) Differential Revision: https://reviews.llvm.org/D48928 llvm-svn: 336415
2018-07-06 14:54:16 +08:00
if (Index / CharByteWidth >= SL->getLength())
return static_cast<char>(0);
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
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
};
Remove unused lambda captures. NFC llvm-svn: 291939
2017-01-14 02:55:32 +08:00
auto GetBigEndianByte = [&SL](unsigned Index) {
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
unsigned CharByteWidth = SL->getCharByteWidth();
[ms] Fix mangling of string literals used to initialize arrays larger or smaller than the literal A Chromium developer reported a bug which turned out to be a mangling collision between these two literals: char s[] = "foo"; char t[32] = "foo"; They may look the same, but for the initialization of t we will (under some circumstances) use a literal that's extended with zeros, and both the length and those zeros should be accounted for by the mangling. This actually makes the mangling code simpler: where it previously had special logic for null terminators, which are not part of the StringLiteral, that is now covered by the general algorithm. (The problem was reported at https://crbug.com/857442) Differential Revision: https://reviews.llvm.org/D48928 llvm-svn: 336415
2018-07-06 14:54:16 +08:00
if (Index / CharByteWidth >= SL->getLength())
return static_cast<char>(0);
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
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] Fix mangling of string literals used to initialize arrays larger or smaller than the literal A Chromium developer reported a bug which turned out to be a mangling collision between these two literals: char s[] = "foo"; char t[32] = "foo"; They may look the same, but for the initialization of t we will (under some circumstances) use a literal that's extended with zeros, and both the length and those zeros should be accounted for by the mangling. This actually makes the mangling code simpler: where it previously had special logic for null terminators, which are not part of the StringLiteral, that is now covered by the general algorithm. (The problem was reported at https://crbug.com/857442) Differential Revision: https://reviews.llvm.org/D48928 llvm-svn: 336415
2018-07-06 14:54:16 +08:00
for (unsigned I = 0, E = StringByteLength; 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
// <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] Fix mangling of char16_t and char32_t to be compatible with MSVC. MSVC limits char16_t and char32_t string literal names to 32 bytes of character data, not to 32 characters. wchar_t string literal names on the other hand can get up to 64 bytes of character data. https://reviews.llvm.org/D48781 llvm-svn: 336097
2018-07-02 20:31:20 +08:00
// <encoded-string>: The mangled name also contains the first 32 bytes
// (including null-terminator bytes) of the encoded StringLiteral.
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
// 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
}
}
};
[ms] Fix mangling of char16_t and char32_t to be compatible with MSVC. MSVC limits char16_t and char32_t string literal names to 32 bytes of character data, not to 32 characters. wchar_t string literal names on the other hand can get up to 64 bytes of character data. https://reviews.llvm.org/D48781 llvm-svn: 336097
2018-07-02 20:31:20 +08:00
// Enforce our 32 bytes max, except wchar_t which gets 32 chars instead.
unsigned MaxBytesToMangle = SL->isWide() ? 64U : 32U;
[ms] Fix mangling of string literals used to initialize arrays larger or smaller than the literal A Chromium developer reported a bug which turned out to be a mangling collision between these two literals: char s[] = "foo"; char t[32] = "foo"; They may look the same, but for the initialization of t we will (under some circumstances) use a literal that's extended with zeros, and both the length and those zeros should be accounted for by the mangling. This actually makes the mangling code simpler: where it previously had special logic for null terminators, which are not part of the StringLiteral, that is now covered by the general algorithm. (The problem was reported at https://crbug.com/857442) Differential Revision: https://reviews.llvm.org/D48928 llvm-svn: 336415
2018-07-06 14:54:16 +08:00
unsigned NumBytesToMangle = std::min(MaxBytesToMangle, StringByteLength);
for (unsigned I = 0; I != NumBytesToMangle; ++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] Fix mangling of string literals used to initialize arrays larger or smaller than the literal A Chromium developer reported a bug which turned out to be a mangling collision between these two literals: char s[] = "foo"; char t[32] = "foo"; They may look the same, but for the initialization of t we will (under some circumstances) use a literal that's extended with zeros, and both the length and those zeros should be accounted for by the mangling. This actually makes the mangling code simpler: where it previously had special logic for null terminators, which are not part of the StringLiteral, that is now covered by the general algorithm. (The problem was reported at https://crbug.com/857442) Differential Revision: https://reviews.llvm.org/D48928 llvm-svn: 336415
2018-07-06 14:54:16 +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
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
}