Enable MSVC STL workaround until next major toolset version

[BurningEnlightenment]

See #98 for further rationale.

[ned14]

I suppose, technically speaking, this issue is really with the MSVC STL and not with MSVC itself so we are using the wrong macro. I generally don't do unconditional workarounds for compiler or library implementations because they prevent said implementers using my code to fix their stuff, which they occasionally do. So we ought to always retain a version comparison of some sort.

May I suggest that we test _CPPLIB_VER instead, but perhaps compare to a version some way off from current so this workaround doesn't drop out for a while? Next time I'm talking to a MSVC person I may drop heavy hints they ought to go improve the story here.

All respect to @StephanTLavavej but the other standard libraries compile this code just fine, and I think his STL needs to try harder here than it currently does. We ought to remind ourselves to chase the MSVC STL maintainers about this stuff eventually.

[BurningEnlightenment]

May I suggest that we test _CPPLIB_VER instead, but perhaps compare to a version some way off from current so this workaround doesn't drop out for a while? Next time I'm talking to a MSVC person I may drop heavy hints they ought to go improve the story here.

I opted for _MSVC_STL_VERSION which seems to be kept in sync with the toolset version (see microsoft/STL#2090). I chose 150, because (as outlined in the issue) they can't fix it without breaking binary compatibility. Which in turn won't happen earlier than the next major toolset version release.

[ned14]

Yes I like _MSVC_STL_VERSION much better, as it is the ABI version of the VS STL.

Surely 150 is a bit aggressive though? It's currently 143 which I would assume will remain until VS2024 is released. It seems reasonable to me that this workaround get retested on VS2024's release.

[BurningEnlightenment]

Surely 150 is a bit aggressive though? It's currently 143 which I would assume will remain until VS2024 is released. It seems reasonable to me that this workaround get retested on VS2024's release.

Maybe I'm wrong, but my understanding is that the number is composed of a major and a minor part (i.e. 14.3). Whereas toolsets with the same major version retain binary compatibility. This would imply that if VS2024 breaks bincompat it will release with _MSVC_STL_VERSION=150. And from reading Stephan's reddit post I gathered that this cannot be fixed without breaking bincompat.

Therefore 150 should be the earliest version which can contain a fix.

EDIT:

other standard libraries compile this code just fine, and I think his STL needs to try harder here than it currently does.

The underlying issue is that MSVC's std::list<T> move constructor is always noexcept(false) due to the fact that the empty list state is implemented with a dynamically allocated sentinel (which is allowed by the standard). This forces std::vector<std::list<T>> to use the std::list copy constructor in order to provide the required strong EH guarantees.

[github-actions]

Unit Test Results

    6 files  ±0  192 suites  ±0   28m 20s ⏱️ - 7m 35s
  57 tests ±0    57 ✔️ ±0  0 💤 ±0  0 ❌ ±0 
360 runs  ±0  360 ✔️ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit fa0940e. ± Comparison against base commit 7986b92.