<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:rnk@google.com" title="Reid Kleckner <rnk@google.com>"> <span class="fn">Reid Kleckner</span></a>
</span> changed
<a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - [ms][dll] clang generates a COFF symbol table that differs from msvc with __declspec(dllimport)"
href="https://llvm.org/bugs/show_bug.cgi?id=26936">bug 26936</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>RESOLVED
</td>
<td>REOPENED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>INVALID
</td>
<td>---
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - [ms][dll] clang generates a COFF symbol table that differs from msvc with __declspec(dllimport)"
href="https://llvm.org/bugs/show_bug.cgi?id=26936#c7">Comment # 7</a>
on <a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - [ms][dll] clang generates a COFF symbol table that differs from msvc with __declspec(dllimport)"
href="https://llvm.org/bugs/show_bug.cgi?id=26936">bug 26936</a>
from <span class="vcard"><a class="email" href="mailto:rnk@google.com" title="Reid Kleckner <rnk@google.com>"> <span class="fn">Reid Kleckner</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=26936#c5">comment #5</a>)
<span class="quote">> Does it make sense for importing func (not foo)?</span >
I see, in this example dllimport is supposed to associate with the
basic_string<char> specialization, not foo. I missed that.
<span class="quote">> 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?</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>