Skip to content

dllimport conflicts with exclude_from_explicit_instantiation. #40363

Open
@llvmbot

Description

@llvmbot
Member
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

llvmbot commented on Mar 9, 2019

@llvmbot
MemberAuthor

assigned to @zmodem

rnk

rnk commented on Mar 11, 2019

@rnk
Collaborator

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

rnk commented on Mar 11, 2019

@rnk
Collaborator

+Louis, since he added the attribute.

zmodem

zmodem commented on Mar 12, 2019

@zmodem
Collaborator

+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

nico commented on Mar 15, 2019

@nico
Contributor

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

nico

nico commented on Nov 20, 2019

@nico
Contributor

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

rnk

rnk commented on Nov 21, 2019

@rnk
Collaborator

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

nico commented on Nov 26, 2019

@nico
Contributor

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

ldionne commented on Jul 19, 2023

@ldionne
Member

35 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugzillaIssues migrated from bugzillac++clang:codegenIR generation bugs: mangling, exceptions, etc.confirmedVerified by a second party

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Participants

    @nico@tru@rnk@pfusik@ldionne

    Issue actions

      dllimport conflicts with exclude_from_explicit_instantiation. · Issue #40363 · llvm/llvm-project