MSVC being stupid (again)?

[Stephan Bergmann]

On 07.03.2018 08:39, Bjoern Michaelsen wrote:
> Im going slightly mad over:
> 
>   https://gerrit.libreoffice.org/#/c/49565/
> 
> it:
> 
> - uses a class which has a move ctor in a std container and a deleted copy
>    ctor, which _should_ be fine
> - compiles fine on OSX and Linux gcc and Linux clang
> - it fails on MSVC with some bull&^(t errors that start off with "I tried to
>    instanciate the deleted copy ctor" (which sounds almost reasonable) but ends
>    with stuff including boost::args. which has ~nothing to do with the changes
>    stl stuff involved and sound like it really took a wrong turn at some place
> - copying and renaming the involved clasess to uwriter seems to make the
>    std::list<SwDepend2> compile just fine
> 
> My gut feeling is that window precompiled headers are hitting a broken corner
> case here. Anyone having any hints?

What I note is that SwDepend has a move ctor but no move assignment op. 
Both SwDepend and WriterMultiListener (containing a std::list<SwDepend> 
member) being SW_DLLPUBLIC, I assume that MSVC wants to instantiate some 
std::list<SwDepend> inline member function that requires SwDepend to be 
MoveAssignable.  Even if that function would never be used (and thus 
Clang/GCC not instantiating it for non-MSVC ABIs, and not running into 
an issue), MSVC would still want to do that when those SW_DLLPUBLIC 
expand to __declspec(dllexport).

(Or maybe it's even trying to instantiate a std::list<SwDepend> member 
function that requires SwDepend to indeed be CopyConstructible.  But, 
without looking deeper now, I would suspect that would be a bug in 
MSVC's standard library.)

Not sure if this could be fixed by making select (implicit) member 
functions of SwDepend and/or WriterMultiListener non-inline and moving 
their definitions out into a .cxx.