`<vector>`: change of behavior on linkage requirement with unused dllimported symbols in MSVC 19.29 and onwards

[StephanTLavavej]

C:\Temp>type meow.cpp

#include <vector>

struct __declspec(dllimport) Cat {
    virtual ~Cat();
};

struct Dog {
    std::vector<Cat> v;

    Dog() { v.emplace_back(); }
};

int main() { }

C:\Temp>cl /EHsc /nologo /W4 /std:c++17 meow.cpp
meow.cpp

C:\Temp>cl /EHsc /nologo /W4 /std:c++20 meow.cpp
meow.cpp
meow.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl Cat::~Cat(void)" (__imp_??1Cat@@UEAA@XZ) referenced in function "public: virtual void * __cdecl Cat::`scalar deleting destructor'(unsigned int)" (??_GCat@@UEAAPEAXI@Z)
meow.exe : fatal error LNK1120: 1 unresolved externals

@cdacamar believes this was regressed by #1546. I don't know enough about dllimport and "scalar deleting destructors" to immediately diagnose this - it may be by design (I know that C++20 constexpr vector required a bunch of our logic to change) or it may be unintentional/avoidable.

Originally reported as DevCom-1635853 and internal VSO-1461416 / AB#1461416 .

[miscco]

I think it is possible to build an old STL commit with the new compiler.

Consequently we should be able to check whether

a) #1546 introduced the problem by building the previous commit. or
b) use git bisect to find the offending commit.

I am not sure whether I will find time for that in the near future. Maybe someone with a beefier machine can try, because it takes some time to build the STL on my machine

[frederick-vs-ja]

I made some naive tests and have got a result: the unwanted linkage requirement is caused by the misinterpretation of the new-expression (which is an unevaluated operand) inside the SFINAE constraint of construct_at (here). Unfortunately I failed to find a workaround.

It seems that MSVC currently requires some symbols for linkage that are only used in unevaluated operands, which is a compiler bug IMO.

Compiler Explorer links:

• reduced example
• furtherly reduced example

[miscco]

I believe we can get around it by using a concept rather than plain old SFINAE. That said I believe there was a reason @StephanTLavavej changed it to use void_t

Looking at you EDG...

[miscco]

Nope, seems like it is also not working inside a concept 😿

[StephanTLavavej]

Thank you @frederick-vs-ja! 😻 I've asked the compiler devs to take a look at this. Keeping this issue open for now.

[frederick-vs-ja]

According to the report in DevCom-1635853, this is fixed in 17.3. Example.

[StephanTLavavej]

Thanks @frederick-vs-ja and @fsb4000 for bringing this up on Discord. This was indeed intentionally fixed by the compiler team who found the root cause (there are details in the internal bug's history). Closing this issue.