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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
A redeclaration may not add dllimport or dllexport attributes. dllexport is
sticky and can be omitted on redeclarations while dllimport cannot.
llvm-svn: 205197
Hans Wennborg