[llvm-bugs] [Bug 38354] Clang-cl generates more code, in this case the Dtor. Resulting in link errors

[via llvm-bugs]

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

Reid Kleckner <rnk at google.com> changed:

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

--- Comment #3 from Reid Kleckner <rnk at google.com> ---
(In reply to JVApen from comment #2)
> I've tested this example with /Zc:inline as well as the whole codebase I'm
> working on for MSVC. This doesn't cause any linking error at all. This makes
> me assume that MSVC handles the implicit default methods differently. (I've
> also noticed something similar for classes containing unique_ptr as member,
> where Dtor also required extra include)
> 
> This makes me assume that this bug ain't just about 'inline' and more about
> the default member functions. Would you mind taking a second look?

MSVC's /Zc:inline isn't that smart. They haven't put much work into discarding
unneeded inline functions, and there is flexibility as to what functions get
discarded. It all boils down to the whims of the inliner, which are not
expected to be stable. In this case, MSVC ends up providing a definition for
A<int>::~A in t.obj, and we don't, and we're allowed not to. At least, we think
we're allowed not to.

> FYI: My current fix for this code is actually to add: B::~B(){} in the Cpp
> (+ matching thing in header)

That'll work OK, but there could be other implicit special members (operator=,
copy ctor) that might need to call methods of A. It's always dicey to declare
template methods in a header without providing definitions.

-- 
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/20180801/def4d61c/attachment.html>