[llvm-bugs] [Bug 26936] [ms][dll] clang generates a COFF symbol table that differs from msvc with __declspec(dllimport)

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26936

Reid Kleckner <rnk at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #7 from Reid Kleckner <rnk at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160316/6f655266/attachment-0001.html>