summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX/dllimport.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [MS] Consder constexpr globals to be inline, as in C++17Reid Kleckner2019-09-111-25/+66
| | | | | | | | | | | | | | | | 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
* 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
* Drop 'dllimport' when redeclaring inline function template without the ↵Hans Wennborg2017-02-011-31/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | attribute (PR31695) For non-template dllimport functions, MSVC allows providing an inline definition without spelling out the attribute again. In the example below, f remains a dllimport function. __declspec(dllimport) int f(); inline int f() { return 42; } int useit() { return f(); } However, for a function template, not putting dllimport on the redeclaration causes it to be dropped. In the example below, f is not dllimport. template <typename> __declspec(dllimport) int f(); template <typename> inline int f() { return 42; } int useit() { return f<int>(); } This patch makes Clang match MSVC for the second example. MSVC does not warn about the attribute being dropped in the example above, but I think we should. (MSVC does warn if the inline keyword isn't used.) Differential Revision: https://reviews.llvm.org/D29152 llvm-svn: 293800
* 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
* [ms][dll] #26935 Defining a dllimport function should cause it to be exportedDenis Zobnin2016-05-251-39/+172
| | | | | | | | | | | | | | | | | | | If we have some function with dllimport attribute and then we have the function definition in the same module but without dllimport attribute we should add dllexport attribute to this function definition. The same should be done for variables. Example: struct __declspec(dllimport) C3 { ~C3(); }; C3::~C3() {;} // we should export this definition. Patch by Andrew V. Tischenko Differential revision: http://reviews.llvm.org/D18953 llvm-svn: 270686
* MS ABI: Don't allow dllexport/import on lambdasHans Wennborg2015-09-151-0/+11
| | | | | | | 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/+1
| | | | | | | | 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/+12
| | | | | | | | | | | | | | | | | | | | | 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
* [Sema] Emit a better diagnostic when variable redeclarations disagreeDavid Majnemer2015-07-141-6/+6
| | | | | | | | | | | We referred to all declaration in definitions in our diagnostic messages which is can be inaccurate. Instead, classify the declaration and emit an appropriate diagnostic for the new declaration and an appropriate note pointing to the old one. This fixes PR24116. llvm-svn: 242190
* 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 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
* Don't dllimport inline functions when targeting MinGW (PR21366)Hans Wennborg2014-11-031-45/+267
| | | | | | | | | | | | It turns out that MinGW never dllimports of exports inline functions. This means that code compiled with Clang would fail to link with MinGW-compiled libraries since we might try to import functions that are not imported. To fix this, make Clang never dllimport inline functions when targeting MinGW. llvm-svn: 221154
* 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
* The dllimport.cpp test was gating some checks on #ifndef MSABI,Hans Wennborg2014-10-281-8/+12
| | | | | | | | | but MSABI was never defined in the test. It seems we are erroring on code that we should be accepting when compiling for MSVC compatibility. This should make the test less confusing until PR21406 is fixed. llvm-svn: 220825
* 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
* Don't assert on different DLL attributes in template and explicit ↵Hans Wennborg2014-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | instantiation (PR20137) We would previously assert (a decl cannot have two DLL attributes) on this code: template <typename T> struct __declspec(dllimport) S { T f() { return T(); } }; template struct __declspec(dllexport) S<int>; The problem was that when instantiating, we would take the attribute from the template even if the instantiation itself already had an attribute. Also, don't inherit DLL attributes from the template to its members before instantiation, as the attribute may change. I couldn't figure out what MinGW does here, so I'm leaving that open. At least we're not asserting anymore. llvm-svn: 216340
* 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
* Don't drop dllimport from qualified friend redeclarations (PR20512)Hans Wennborg2014-08-041-0/+7
| | | | | | | | | | This matches MSVC's logic, which seems to be that when the friend declaration is qualified, it cannot be a declaration of a new symbol and so the dll linkage doesn't change. Differential Revision: http://reviews.llvm.org/D4764 llvm-svn: 214774
* 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-0/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+9
| | | | llvm-svn: 211648
* Don't inherit dll attributes to deleted methods (PR19988)Hans Wennborg2014-06-101-0/+8
| | | | | | | | | | | | | We would previously end up with an error when instantiating the following template: template <typename> struct __declspec(dllimport) S { void foo() = delete; }; S<int> s; error: attribute 'dllimport' cannot be applied to a deleted function llvm-svn: 210550
* Downgrade "definition of dllimport static field" error to warning for class ↵Hans Wennborg2014-06-041-12/+19
| | | | | | | | | | | | | | | | | | | templates (PR19902) This allows us to compile the following kind of code, which occurs in MSVC headers: template <typename> struct S { __declspec(dllimport) static int x; }; template <typename T> int S<T>::x; The definition works similarly to a dllimport inline function definition and gets available_externally linkage. Differential Revision: http://reviews.llvm.org/D3998 llvm-svn: 210141
* Diagnose dll attribute on member of class that already has a dll attributeHans Wennborg2014-05-311-2/+24
| | | | | | Differential Revision: http://reviews.llvm.org/D3973 llvm-svn: 209954
* Start adding support for dllimport/dllexport on classes (PR11170)Hans Wennborg2014-05-301-9/+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/+19
| | | | llvm-svn: 209827
* Sema: Check dll attributes on static data membersNico Rieck2014-05-291-0/+182
| | | | | | | 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/+391
| | | | llvm-svn: 209598
* Sema: Add dll attribute tests for variable templatesNico Rieck2014-05-251-0/+80
| | | | llvm-svn: 209597
* Sema: Add more tests for dll attributes on inline functionsNico Rieck2014-05-231-1/+49
| | | | llvm-svn: 209542
* Fix typoNico Rieck2014-05-231-1/+1
| | | | llvm-svn: 209540
* Allow dllimport/dllexport on inline functions and adjust the linkage.Hans Wennborg2014-05-151-7/+7
| | | | | | | | 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/+23
| | | | llvm-svn: 205198
* Sema: Check dll attributes on redeclarationsNico Rieck2014-03-311-12/+58
| | | | | | | A redeclaration may not add dllimport or dllexport attributes. dllexport is sticky and can be omitted on redeclarations while dllimport cannot. llvm-svn: 205197
* Fix tests in r204576Nico Rieck2014-03-231-4/+4
| | | | | | Proper redeclaration warnings for dllimport are not implemented yet. llvm-svn: 204577
* Treat dllimport globals without explicit storage class as externNico Rieck2014-03-231-0/+27
| | | | | | | dllimport implies a definition which means the 'extern' keyword is optional when declaring imported variables. llvm-svn: 204576
* Sema: Definition of dllimport globals is not allowedNico Rieck2014-02-261-5/+9
| | | | | | | 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/+127
llvm-svn: 201947
OpenPOWER on IntegriCloud