https://llvm.org/bugs/show_bug.cgi?id=26936
Reid Kleckner <r...@google.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #7 from Reid Kleckner <r...@google.com> ---
(In reply to comment #5)
> Does it make sense for importing func (not foo)?
I see, in this example dllimport is supposed to associate with the
basic_string<char> specialization, not foo. I missed that.
> And one more comment. MSDN says:"As a rule, everything that is accessible to
> the DLL's client (according to C++ access rules) should be part of the
> exportable interface". In our case foo<char>().func() returns class and our
> client uses the method of the class that's why this method should be
> accessible from the dll. Am I right?
Well, this is really a rule for the user to follow, not so much the compiler.
I think there are two issues here:
1. Allow dllimport to appear in elaborated tag type specifiers like in this
example:
template <class _E> struct basic_string { void func(); };
void bar(struct __declspec(dllimport) basic_string<char> &s) { s.func(); }
2. Allow dllimport to be applied to templates after instantiation, as in this
example:
template <class _E> struct basic_string { void func(); };
void bar(struct basic_string<char> &s) { s.func(); }
extern template struct __declspec(dllimport) basic_string<char>;
The first can probably be done, but the second might be infeasible. By the time
we see the dllimport attribute, we've already done some IRGen and made
assumptions about the constexpr-ness of various static data members.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
