Quuxplusone
commented
5 years ago Basically, we have two things that say the function will be externally
available, one from the language (extern template) and one extension
(dllimport), and then we have our own, new extension
(exclude_from_expicit_instantiation), which says the opposite. I guess the
"negative" available_externally attribute should win, since it only exists to
say that an inline function is *not* available_externally.
I wonder if it makes sense to extend this attribute to work in non-template
cases, consider:
class EXPORT Foo {
// Too many methods to individually annotate with EXPORT:
void baz00();
void baz01();
...
void baz99();
// One inline method that I don't want to export, for whatever reason:
int __attribute__((exclude_from_explicit_instantiation)) bar() {
return 42;
}
};
Obviously, the spelling "exclude_from_explicit_instantiation" doesn't make any
sense, but what's really been created here is an available_externally-blocker
attribute.
The same effect can also be achieved with clang-cl /Zc:dllExportInlines-, by
the way: http://blog.llvm.org/2018/11/30-faster-windows-builds-with-clang-
cl_14.html
Speculatively assigning to Hans since he supervised /Zc:dllExportInlines-.
When both dllimport and exclude_from_explicit_instantiation are passed, Clang still expects the function to have a externally available definition. But this is not the case.
For example: https://godbolt.org/z/gKOHCk
This leads to linker errors because of undefined symbols.
I think one approach would be to make Clang not inherit
dllimportattributes on functions declared with exclude_from_explicit_instantiation. When dllimport is applied directly, we could emit an error for incompatible attributes.