dllimport conflicts with exclude_from_explicit_instantiation.

[llvmbot]

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.

[llvmbot]

assigned to @zmodem

[rnk]

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]

+Louis, since he added the attribute.

[zmodem]

+Louis, since he added the attribute.

(For anyone looking, that was r343790.)

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.

That sounds reasonable to me.

[nico]

ldionne, as author of exclude_from_explicit_instantiation could you take a look? libc++ currently needs to carry a workaround for this.

[nico]

libc++ will need another workaround for this for https://bugs.chromium.org/p/chromium/issues/detail?id=923166#c44

[rnk]

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]

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]

Tentative fix: https://reviews.llvm.org/D155713