Open
Description
Bugzilla Link | 41018 |
Version | trunk |
OS | All |
Reporter | LLVM Bugzilla Contributor |
CC | @DougGregor,@zmodem,@ldionne,@nico,@zygoloid,@rnk |
Extended Description
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 dllimport
attributes on functions declared with exclude_from_explicit_instantiation. When dllimport is applied directly, we could emit an error for incompatible attributes.
Activity
llvmbot commentedon Mar 9, 2019
assigned to @zmodem
rnk commentedon Mar 11, 2019
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-.
rnk commentedon Mar 11, 2019
+Louis, since he added the attribute.
zmodem commentedon Mar 12, 2019
(For anyone looking, that was r343790.)
That sounds reasonable to me.
nico commentedon Mar 15, 2019
ldionne, as author of exclude_from_explicit_instantiation could you take a look? libc++ currently needs to carry a workaround for this.
nico commentedon Nov 20, 2019
libc++ will need another workaround for this for https://bugs.chromium.org/p/chromium/issues/detail?id=923166#c44
rnk commentedon Nov 21, 2019
Separately from what clang should do, does Chromium use the libc++ ABI unstable macros? Can it?
If so, I would think that the "unstable ABI" build shouldn't use the exclude_from_explicit_instantiation attributes, since I believe those are only needed to stabilize the ABI.
nico commentedon Nov 26, 2019
Yes, Chromium sets _LIBCPP_ABI_UNSTABLE (except, for now, in branded CrOS builds, but that's hopefully temporary).
That sounds like a good idea to me.
(Having said that, updating libc++ in Chromium is a bit of a mess atm, so a compiler-side fix might still help Chromium earlier even if we implemented that suggestion for libc++ very soon and the compiler fix a bit later.)
ldionne commentedon Jul 19, 2023
Tentative fix: https://reviews.llvm.org/D155713
[libc++] Work around dynamic linking of stringbuf::str() on Windows
35 remaining items