summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX/dllexport.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [MS] Consder constexpr globals to be inline, as in C++17Reid Kleckner2019-09-111-8/+29
| | | | | | | | | | | | | | | | Summary: Microsoft seems to do this regardless of the language mode, so we must also do it in order to be ABI compatible. Fixes PR36125 Reviewers: thakis Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47956 llvm-svn: 371642
* [MinGW] Fix dllexport of explicit template instantiationMartin Storsjo2019-04-261-5/+24
| | | | | | | | | | | | | | | | | Contrary to MSVC, GCC/MinGW needs to have the dllexport attribute on the template instantiation declaration, not on the definition. Previously clang never marked explicit template instantiations as dllexport in MinGW mode, if the instantiation had a previous declaration, regardless of where the attribute was placed. This makes Clang behave like GCC in this regard, and allows using the same attribute form for both MinGW compilers. This fixes PR40256. Differential Revision: https://reviews.llvm.org/D61118 llvm-svn: 359285
* Ensure that const variables declared at namespace scope correctly have ↵Aaron Ballman2019-03-191-0/+4
| | | | | | | | external linkage when marked as dllexport and targeting the MSVC ABI. Patch thanks to Zahira Ammarguellat. llvm-svn: 356458
* Determine the attribute subject for diagnostics based on declarative ↵Aaron Ballman2017-11-261-8/+8
| | | | | | | | | | information in DeclNodes.td. This greatly reduces the number of enumerated values used for more complex diagnostics; these are now only required when the "attribute only applies to" diagnostic needs to be generated manually as part of semantic processing. This also clarifies some terminology used by the diagnostic (methods -> Objective-C methods, fields -> non-static data members, etc). Many of the tests needed to be updated in multiple places for the diagnostic wording tweaks. The first instance of the diagnostic for that attribute is fully specified and subsequent instances cut off the complete list (to make it easier if additional subjects are added in the future for the attribute). llvm-svn: 319002
* [MS] Instantiate default args during instantiation of exported default ctorsReid Kleckner2017-01-051-0/+21
| | | | | | | | | | | | | | | | | | | | Summary: Replace some old code that probably pre-dated the change to delay emission of dllexported code until after the closing brace of the outermost record type. Only uninstantiated default argument expressions need to be handled now. It is enough to instantiate default argument expressions when instantiating dllexported default ctors. This also fixes some double-diagnostic issues in this area. Fixes PR31500 Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28274 llvm-svn: 291045
* Sema: support __declspec(dll*) on ObjC interfacesSaleem Abdulrasool2016-07-151-6/+12
| | | | | | | | | | | Extend the __declspec(dll*) attribute to cover ObjC interfaces. This was requested by Microsoft for their ObjC support. Cover both import and export. This only adds the semantic analysis portion of the support, code-generation still remains outstanding. Add some basic initial documentation on the attributes that were previously empty. Tweak the previous tests to use the relative expected-warnings to make the tests easier to read. llvm-svn: 275610
* [MSVC Compat] Diagnose multiple default ctors for dllexport'd classesDavid Majnemer2015-12-311-1/+6
| | | | | | | | | | | | | | | | | The MS ABI emits a special default constructor closure thunk if a default constructor has a weird calling convention or default arguments. The MS ABI has a quirk: there can be only one such thunk because the mangling scheme does not have room for distinct manglings. We must raise a diagnostic in this eventuality. N.B. MSVC sorta gets this right. Multiple default constructors result in the default constructor closure getting emitted but they seem to get confused by which default constructors are reasonable to reference from the closure. We try to be a little more careful which results in mild differences in behavior. llvm-svn: 256661
* MS ABI: Don't allow dllexport/import on lambdasHans Wennborg2015-09-151-0/+9
| | | | | | | This is to follow up on David's comment in http://reviews.llvm.org/D12422#235509 llvm-svn: 247718
* Don't allow dllexport/import on static local variablesHans Wennborg2015-09-041-7/+2
| | | | | | | | They might technically have external linkage, but it still doesn't make sense for the user to try and export such variables. This matches MSVC's and MinGW's behaviour. llvm-svn: 246864
* Allow TLS vars in dllimport/export functions; only inline dllimport ↵Hans Wennborg2015-08-281-0/+9
| | | | | | | | | | | | | | | | | | | | | functions when safe (PR24593) This patch does two things: 1) Don't error about dllimport/export on thread-local static local variables. We put those attributes on static locals in dllimport/export functions implicitly in case the function gets inlined. Now, for TLS variables this is a problem because we can't import such variables, but it's a benign problem becase: 2) Make sure we never inline a dllimport function TLS static locals. In fact, never inline a dllimport function that references a non-imported function or variable (because these are not defined in the importing library). This seems to match MSVC's behaviour. Differential Revision: http://reviews.llvm.org/D12422 llvm-svn: 246338
* Enable propagation of dll attributes to previously instantiated base class ↵Hans Wennborg2015-06-091-5/+9
| | | | | | | | | | | | | | | templates in some cases It is safe to add a dll attribute if the base class template previously only had an explicit instantiation declaration, or was implicitly instantiated. I both those cases, the members would not have been codegenned yet. In the case of explicit instantiation declaration this is natural, and for implicit instantiations, codegen is deferred (see r225570). This is work towards fixing PR23770. llvm-svn: 239373
* Narrow the -Wunsupported-dll-base-class-template warning.Hans Wennborg2015-06-091-7/+3
| | | | | | | | | | | | | Don't warn about not being able to propagate dll attribute to a base class template when that base already has a different attribute. MSVC doesn't actually try to do this; the first attribute that was propagated takes precedence, so Clang is already doing the right thing and there's no need to warn. (This is a step towards fixing PR21718.) llvm-svn: 239372
* __declspec is not a core Clang language extension. Instead, require ↵Aaron Ballman2015-05-261-4/+4
| | | | | | | -fms-extensions or -fborland to enable the language extension. Note: __declspec is also temporarily enabled when compiling for a CUDA target because there are implementation details relying on __declspec(property) support currently. When those details change, __declspec should be disabled for CUDA targets. llvm-svn: 238238
* Don't dllimport/export class members with internal linkage (PR23308)Hans Wennborg2015-04-221-0/+6
| | | | | | | | | | For example, a function taking a parameter with internal linkage will itself have internal linkage since it cannot be called outside the translation unit. Differential Revision: http://reviews.llvm.org/D9182 llvm-svn: 235471
* Warn about dllexported explicit class template instantiation declarations ↵Hans Wennborg2015-01-151-2/+7
| | | | | | | | | | | | | | | (PR22035) Clang would previously become confused and crash here. It does not make a lot of sense to export these, so warning seems appropriate. MSVC will export some member functions for this kind of specializations, whereas MinGW ignores the dllexport-edness. The latter behaviour seems better. Differential Revision: http://reviews.llvm.org/D6984 llvm-svn: 226208
* Don't allow dllimport/export on classes with internal linkage (PR21399)Hans Wennborg2014-11-031-0/+4
| | | | | | | | | | | Trying to import or export such classes doesn't make sense, and Clang would assert trying to export vtables for them. This is consistent with how we treat functions with internal linkage, but it is stricter than MSVC so we may have to back down if it breaks real code. llvm-svn: 221160
* Follow-up to r216619: use isCXXCLassMember() instead of trying toHans Wennborg2014-10-291-1/+11
| | | | | | | check the context ourselves when selectively allowing late-added dll attributes on unused free functions and variables (PR20746) llvm-svn: 220874
* MS ABI: Disallow dllimported/exported variables from having TLSDavid Majnemer2014-10-041-0/+3
| | | | | | | | | | | | | | | | | | | Windows TLS relies on indexing through a tls_index in order to get at the DLL's thread local variables. However, this index is not exported along with the variable: it is assumed that all accesses to thread local variables are inside the same module which created the variable in the first place. While there are several implementation techniques we could adopt to fix this (notably, the Itanium ABI gets this for free), it is not worth the heroics. Instead, let's just ban this combination. We could revisit this in the future if we need to. This fixes PR21111. llvm-svn: 219049
* Allow adding dll attributes on certain redecls with a warning if the decl ↵Hans Wennborg2014-08-271-5/+5
| | | | | | | | | | | | hasn't been used yet (PR20746) This shouldn't really be allowed, but it comes up in real code (see PR). As long as the decl hasn't been used there's no technical difficulty in supporting it, so downgrade the error to a warning. Differential Revision: http://reviews.llvm.org/D5087 llvm-svn: 216619
* Ignore -Wunsupported-dll-base-class-template by defaultHans Wennborg2014-08-221-4/+4
| | | | | | | | The situation it is warning about (see PR20725) is not very likely to be a real problem, and it is unclear what action the user should take if the warning does fire. llvm-svn: 216283
* MS ABI: Don't always instantiate all members of dllexported class templates ↵Hans Wennborg2014-08-211-0/+43
| | | | | | | | | | | | | | | | (PR20163) Normally we mark all members of exported classes referenced to get them emitted. However, MSVC doesn't do this for class templates that are implicitly specialized or just have an explicit instantiation declaration. For such specializations, the members are emitted when referenced. The exception is the case when the dllexport attribute is propagated from a base class to a base class template that doesn't have an explicit attribute: in this case all methods of the base class template do get instantiated. llvm-svn: 216145
* Avoid non-attributive uses of 'unsupported' in diagnosticsAlp Toker2014-07-141-4/+4
| | | | | | | | | | | | | We don't have a style guide for diagnostic messages, but convention strongly favours the forms: 'attribute is not supported', 'unsupported attribute' We generally avoid: 'attribute is unsupported', 'non-supported attribute' llvm-svn: 212972
* MS ABI: Propagate class-level DLL attributes to class template ↵Hans Wennborg2014-06-251-1/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | specialization bases (PR11170) Consider the following code: template <typename T> class Base {}; class __declspec(dllexport) class Derived : public Base<int> {} When the base of an exported or imported class is a class template specialization, MSVC will propagate the dll attribute to the base. In the example code, Base<int> becomes a dllexported class. This commit makes Clang do the proopagation when the base hasn't been instantiated yet, and warns about it being unsupported otherwise. This is different from MSVC, which allows changing a specialization back and forth between dllimport and dllexport and seems to let the last one win. Changing the dll attribute after instantiation would be hard for us, and doesn't seem to come up in practice, so I think this is a reasonable limitation to have. MinGW doesn't do this kind of propagation. Differential Revision: http://reviews.llvm.org/D4264 llvm-svn: 211725
* MS ABI: Ignore dll attributes on partial template specializationsHans Wennborg2014-06-241-2/+13
| | | | llvm-svn: 211648
* Start adding support for dllimport/dllexport on classes (PR11170)Hans Wennborg2014-05-301-8/+18
| | | | | | | | | | | | | | | | This implements the central part of support for dllimport/dllexport on classes: allowing the attribute on class declarations, inheriting it to class members, and forcing emission of exported members. It's based on Nico Rieck's patch from http://reviews.llvm.org/D1099. This patch doesn't propagate dllexport to bases that are template specializations, which is an interesting problem. It also doesn't look at the rules when redeclaring classes with different attributes, I'd like to do that separately. Differential Revision: http://reviews.llvm.org/D3877 llvm-svn: 209908
* Sema: Functions with dll attributes cannot be deletedNico Rieck2014-05-291-0/+16
| | | | llvm-svn: 209827
* Sema: Check dll attributes on static data membersNico Rieck2014-05-291-0/+157
| | | | | | | Redeclarations cannot add a dll attribute and static data members cannot be defined. llvm-svn: 209825
* Sema: Add dll attribute tests for member functionsNico Rieck2014-05-251-0/+388
| | | | llvm-svn: 209598
* Sema: Add dll attribute tests for variable templatesNico Rieck2014-05-251-0/+77
| | | | llvm-svn: 209597
* Sema: Add more tests for dll attributes on inline functionsNico Rieck2014-05-231-0/+20
| | | | llvm-svn: 209542
* Allow dllimport/dllexport on inline functions and adjust the linkage.Hans Wennborg2014-05-151-5/+5
| | | | | | | | This is a step towards handling these attributes on classes (PR11170). Differential Revision: http://reviews.llvm.org/D3772 llvm-svn: 208925
* Some more anonymous namespace diagnostics to switch to ()David Blaikie2014-04-021-3/+3
| | | | llvm-svn: 205400
* Sema: Require external linkage for dll attributesNico Rieck2014-03-311-0/+26
| | | | llvm-svn: 205198
* Sema: Check dll attributes on redeclarationsNico Rieck2014-03-311-2/+38
| | | | | | | A redeclaration may not add dllimport or dllexport attributes. dllexport is sticky and can be omitted on redeclarations while dllimport cannot. llvm-svn: 205197
* Sema: Definition of dllimport globals is not allowedNico Rieck2014-02-261-3/+3
| | | | | | | Upgrades the warning to an error and clarifies the message by treating the definition as error instead of the attribute. llvm-svn: 202300
* Reorganize and improve semantic tests for dllexport/importNico Rieck2014-02-221-0/+189
llvm-svn: 201947
OpenPOWER on IntegriCloud