vNext: Make the abi-breaking-changes branch available on GitHub

[jonwil]

There are a number of issues out there (both listed here on the STL repository and also things like https://developercommunity.visualstudio.com/content/problem/193041/the-visual-c-2017-condition-variable-implementatio.html listed on the Visual C++ bug tracker) that are listed as being fixable but only in whatever the next release is that breaks ABI. There are likely people who want those fixes and would be quite happy using their own STL build that broke the ABI if it meant getting those fixes sooner.

I suggest you consider releasing the ABI breaking changes in a way that those who know what they are doing and want something that breaks ABI can get them. (but where anyone who doesn't explicitly download the ABI-breaking-changes branch wont have to worry) Or if its not possible to publish this stuff (either because there are also ABI changes in vcruntime, vcstartup, concrt or other non-open bits or because vcruntime, vcstartup, concrt or other non-open bits need recompiling with the new ABI-breaking code to pick up the new ABI) then at least consider publishing a comprenensive accurate list of the things that have/can be fixed but only by breaking ABI (so people know where the STL has bugs (or differences with the C++ standards and why they can't be fixed at this time)

[vrubleg]

Yeah, I understand it, it was rather a joke question while we are looking forward to official announcements. Thanks for your work and openness regarding to STL =)

[TheStormN]

Hello and sorry to bother you again @StephanTLavavej :) Hope you are doing well. I see that STL is in top shape for C++23. Thanks to you and your teammates. Keep up the good work!

Given all that, I'm wondering. C++26 is far away, C++23(at least on the STL side) is completed(the compiler teams seems to be lacking behind a lot this time, hopefully they will catch up soon).

So, do you have any plans to pause for a bit the feature work and open the doors on vNext? In general, do you have anything interesting to share at this moment? :)

[cpplearner]

Please upvote https://developercommunity.visualstudio.com/t/Support-for-breaking-the-STL-ABI/1473763

[StephanTLavavej]

We're trying to get approval, but nothing to share at the moment.

[Sedeniono]

Mostly out of curiosity: The STL release 17.10 contains an ABI break due to the constexpr mutex constructor (#4338). As far as I understood it, the new STL headers combined with old STL-DLLs cause crashes. But old headers with new DLLs work. So apparently (and according to the documentation) this kind of ABI break is accepted by Microsoft.

My question: How does vNext relate to this? Why was #4338 not a vNext issue? Do all issues tagged with vNext break the compatibility of old headers with newer DLLs (i.e. the other way around compared to #4338)?

[TheStormN]

vNext breaks it in such a way that already compiled binaries and static libraries will become unusable. Nothing more, nothing less.

[jonwil]

"ABI breaking change" means a change that will cause existing compiled code that uses the STL (that is, compiled object code that needs to be linked with libcp or msvcp libraries) to either fail to link or to fail to run properly after its linked with the libcp or msvcp library version that contains the "ABI breaking change"

[StephanTLavavej]

Yes, our binary compatibility is explicitly documented as one-way, allowing applications to use prebuilt third-party libraries, but not the other way around. We regularly exercise the requirement that the final link be performed by the newest toolset. constexpr mutex construction exercised the requirement that the VCRedist be from the newest toolset - we really ought to exercise that requirement more frequently, and I've made a note that we should do that for vNext.

v14 => vNext will be a total ABI break (like VS 2008 => 2010 => 2012 => 2013 => 2015), including renaming all of the versioned DLLs. No OBJ/LIB mixing will be possible, and DLL/EXE mixing will work only if the DLL interfaces are ABI-stable (e.g. COM, or completely extern "C" with no trace of STL types, etc.). We're going to change the representations of tons of types, and remove/change a ton of STL DLL exports. vNext is how C++ development is ordinarily done - it's preserving binary compatibility that is extremely difficult and requires unusual development practices that very few people outside our maintainer/contributor team are familiar with.