summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/MicrosoftMangle.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Improve the representation of CXXUuidofExprDavid Majnemer2016-03-271-1/+1
| | | | | | | | Keep a pointer to the UuidAttr that the CXXUuidofExpr corresponds to. This makes translating from __uuidof to the underlying constant a lot more straightforward. llvm-svn: 264529
* [MS ABI] Mangle symbols names longer than 4096 characters correctlyDavid Majnemer2016-03-071-42/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [OPENMP 4.0] Initial support for 'omp declare reduction' construct.Alexey Bataev2016-03-031-2/+4
| | | | | | | | | | | | | | | | | 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
* Revert "Revert r260388 "[MS ABI] Never reference dllimport'd vtables""David Majnemer2016-02-111-1/+4
| | | | | | | | | | | | | 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
* Revert r260388 "[MS ABI] Never reference dllimport'd vtables"Hans Wennborg2016-02-101-4/+1
| | | | | | | This caused the compiler to fail with "invalid linkage type for global declaration" (PR26569). llvm-svn: 260449
* [MS ABI] Never reference dllimport'd vtablesDavid Majnemer2016-02-101-1/+4
| | | | | | | | | | | | | Referencing a dllimported vtable is impossible in a constexpr constructor. It would be friendlier to C++ programmers if we synthesized a copy of the vftable which referenced imported virtual functions. This would let us initialize the object in a way which preserves both the intent to import functionality from another DLL while also making constexpr work. Differential Revision: http://reviews.llvm.org/D17061 llvm-svn: 260388
* [MS ABI] Don't crash while mangling recursive lambdasDavid Majnemer2016-01-171-4/+12
| | | | | | | | | | | | | | | 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
* [OpenCL] Pipe type supportXiuli Pan2016-01-091-0/+9
| | | | | | | | | | | | | | | 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
* [MS ABI] Remove mangleCXXCatchHandlerTypeDavid Majnemer2015-12-311-11/+0
| | | | | | It's dead code, no functional change is intended. llvm-svn: 256664
* [MS ABI] Change the ArgBackRefMap to hold const qualified pointersDavid Majnemer2015-12-311-2/+2
| | | | | | Just a cleanup, no functional change is intended. llvm-svn: 256663
* [MS ABI] Replace dead code with an assertionDavid Majnemer2015-12-311-2/+4
| | | | | | | 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
* Silencing a -Wcast-qual warning; NFC.Aaron Ballman2015-12-301-1/+1
| | | | llvm-svn: 256644
* [MS ABI] Add variable templates to the NameBackReferencesDavid Majnemer2015-12-301-1/+1
| | | | | | | | Only function template specializations are exempt from being added to the NameBackReferences. Redundant variable template specializations should be appropriately substituted. llvm-svn: 256623
* [MS ABI] Improve our mangling of pass_object_sizeDavid Majnemer2015-12-301-4/+30
| | | | | | | | | | | | | | 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
* [MS ABI] Invent a mangling for reference temporariesDavid Majnemer2015-12-291-6/+6
| | | | | | | | | 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
* [MS ABI] Add a mangling for _ComplexDavid Majnemer2015-12-291-5/+10
| | | | | | | | | | | | | 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
* [MS ABI] Mark an unreachable path appropriatelyDavid Majnemer2015-12-291-8/+2
| | | | | | No functional change is intended, just a small cleanup. llvm-svn: 256582
* [MS ABI] Implement a mangling for _Atomic typesDavid Majnemer2015-12-291-5/+10
| | | | | | | | | | | | | 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
* [MS ABI] Cleanup our mangling of vector typesDavid Majnemer2015-12-291-10/+13
| | | | | | | | | | | | | | 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
* [MS ABI] Cleanup the mangling of artifical typesDavid Majnemer2015-12-291-46/+97
| | | | | | | Hand-rolling the mangling results in us not correctly adding names to the backreference map. llvm-svn: 256555
* Fix funciton->function typo.Eric Christopher2015-12-161-1/+1
| | | | llvm-svn: 255840
* Add the `pass_object_size` attribute to clang.George Burgess IV2015-12-021-2/+14
| | | | | | | | | | | | | `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
* [MS ABI] Correctly mangle nullptr member pointers for variable templatesDavid Majnemer2015-12-011-3/+3
| | | | | | | Variable templates behave the same as class templates with regard to nullptr memeber pointers. llvm-svn: 254439
* Add support for GCC's '__auto_type' extension, per the GCC manual:Richard Smith2015-11-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [MS ABI] Mangle static anonymous unionsDavid Majnemer2015-10-221-2/+3
| | | | | | | | | | | | 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
* [coroutines] Add overloaded unary 'operator co_await'.Richard Smith2015-10-221-0/+8
| | | | llvm-svn: 250991
* Run clang-format to unify the switch statement style as suggest here: ↵Alexey Bader2015-09-151-37/+103
| | | | | | | | http://reviews.llvm.org/D12855#246073. NFC. llvm-svn: 247678
* [OpenCL] Add new types for OpenCL 2.0.Alexey Bader2015-09-151-0/+30
| | | | | | | | Patch by Pedro Ferreira. Reviewers: pekka.jaaskelainen Differential Revision: http://reviews.llvm.org/D12855 llvm-svn: 247676
* CFI: Introduce -fsanitize=cfi-icall flag.Peter Collingbourne2015-09-101-17/+0
| | | | | | | | | | This flag causes the compiler to emit bit set entries for functions as well as runtime bitset checks at indirect call sites. Depends on the new function bitset mechanism. Differential Revision: http://reviews.llvm.org/D11857 llvm-svn: 247238
* [MS ABI] Number unnamed TagDecls which aren't externally visibleDavid Majnemer2015-09-021-1/+3
| | | | | | | | | | | | 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
* [MS ABI] Switch to the CRC implementation in LLVMDavid Majnemer2015-09-011-29/+5
| | | | | | | We now have an implementation of the CRC in LLVM's libSupport. Let's consolidate around that one. llvm-svn: 246591
* [MS ABI] Correctly mangle classes without names for linkage purposesDavid Majnemer2015-08-311-3/+10
| | | | | | | | | | | | | | | | 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
* Remove and forbid raw_svector_ostream::flush() calls.Yaron Keren2015-08-131-1/+0
| | | | | | | | | | After r244870 flush() will only compare two null pointers and return, doing nothing but wasting run time. The call is not required any more as the stream and its SmallString are always in sync. Thanks to David Blaikie for reviewing. llvm-svn: 244928
* AST: Implement mangling support for function types without a prototype.Peter Collingbourne2015-08-071-4/+10
| | | | | | | | | | 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
* [MS ABI] Create a mangling for extended vector typesDavid Majnemer2015-08-011-7/+3
| | | | | | Extended vector types are mangled just like normal vector types. llvm-svn: 243828
* [MS ABI] nullptr data member ptrs are mangled differently for classes vs fnsDavid Majnemer2015-07-021-3/+15
| | | | | | | | | | | 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
* [MS ABI] Account for the virtual inheritance quirk when manglingDavid Majnemer2015-06-231-1/+8
| | | | | | | | | | | | 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
* [MS ABI] Rework member pointer conversionDavid Majnemer2015-06-231-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-1/+1
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-1/+1
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* CFI: Implement bitset emission for the Microsoft ABI.Peter Collingbourne2015-06-191-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang's control flow integrity implementation works by conceptually attaching "tags" (in the form of bitset entries) to each virtual table, identifying the names of the classes that the virtual table is compatible with. Under the Itanium ABI, it is simple to assign tags to virtual tables; they are simply the address points, which are available via VTableLayout. Because any overridden methods receive an entry in the derived class's virtual table, a check for an overridden method call can always be done by checking the tag of whichever derived class overrode the method call. The Microsoft ABI is a little different, as it does not directly use address points, and overrides in a derived class do not cause new virtual table entries to be added to the derived class; instead, the slot in the base class is reused, and the compiler needs to adjust the this pointer at the call site to (generally) the base class that initially defined the method. After the this pointer has been adjusted, we cannot check for the derived class's tag, as the virtual table may not be compatible with the derived class. So we need to determine which base class we have been adjusted to. Specifically, at each call site, we use ASTRecordLayout to identify the most derived class whose virtual table is laid out at the "this" pointer offset we are using to make the call, and check the virtual table for that tag. Because address point information is unavailable, we "reconstruct" it as follows: any virtual tables we create for a non-derived class receive a tag for that class, and virtual tables for a base class inside a derived class receive a tag for the base class, together with tags for any derived classes which are laid out at the same position as the derived class (and therefore have compatible virtual tables). Differential Revision: http://reviews.llvm.org/D10520 llvm-svn: 240117
* [MS ABI] Be a little more defensive wrt vector typesDavid Majnemer2015-06-011-14/+20
| | | | | | | | | 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
* [MS ABI] Implement restrict qualified referencesDavid Majnemer2015-05-261-65/+74
| | | | | | MSVC 2015 supports '__restrict' qualified reference types. llvm-svn: 238166
* [MS ABI] Give __attribute__((overloadable)) functions pretty namesDavid Majnemer2015-05-181-2/+9
| | | | | | | | 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
* [MS ABI] Function encodings are always encoded in template argumentsDavid Majnemer2015-05-181-9/+14
| | | | llvm-svn: 237547
* Give isCompatibleWithMSVC a better interfaceDavid Majnemer2015-05-111-1/+2
| | | | | | | We now use an enum which maps the marketing name (almost always a year) to the major version number. llvm-svn: 236967
* [MS ABI] Make sure we number thread_local statics seperatelyDavid Majnemer2015-05-071-4/+2
| | | | | | | The thread_local variables need their own numbers, they can't share with the other static local variables. llvm-svn: 236774
* [MS ABI] Implement thread-safe initialization using the MSVC 2015 ABIDavid Majnemer2015-05-071-11/+18
| | | | | | | | | 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
* Replace GetNumBytesInBuffer() in MicrosoftCXXNameMangler::mangleArgumentType ↵Yaron Keren2015-05-021-2/+2
| | | | | | | | | | | | | | | | | | | | | 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
* [MS ABI] Rephrase the mangling of array types in parametersDavid Majnemer2015-04-271-6/+5
| | | | | | Make the canonicalization of array types more consistent. llvm-svn: 235831
OpenPOWER on IntegriCloud