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)

[MikeGitb]

I think the best thing (and I believe they already plan to do it) would be to put the code into a separate branch here on github, but not to ship it in any official form.

The worst possible outcome would be both version being shipped and supported for quite some time in parallel and people to start #ifdef ing their code based on which version the code is built against and incompatible binaries floating around. Imo that would be a disservice to the eco system.

All that aside: I guess one of the problems may be that those patches no longer apply cleanly to the current master version of the code.

[jonwil]

Releasing it as a separate branch is the answer for sure. People who want to ship it can grab that branch and get a set of binaries out of it knowing full well those dlls are ABI-breaking compared to the official binaries.

Of course it may not be possible to publish the code at all if the ABI-breaking branch would require changes to the compiler or changes or recompilation of other non-open binaries like vcruntime, vcstartup or concrt (that said, it looks like concrt is the only runtime library component shipped with the compiler that actually links to and pulls in the STL so its entirely possible the answer to any problems with an ABI incompatible STL solved by making concrt open source, something that would be nice to see anyway given the circular dependency between concrt and STL)

[sylveon]

ABI breaking STL could be released on vcpkg. To avoid conflicts with the built-in STL, the headers could be located under another folder, like so: #include <stl/string>

[CaseyCarter]

We do plan to get the binary-breaking branch integrated here eventually; we effectively must do so to achieve our goal of primarily developing the STL out of this repository. I would in no way refer to those plans as "releasing" so much as "developing", we still have quite a few ABI-breaking changes that need to be implemented on that branch.

@MikeGitb's "I guess one of the problems may be that those patches no longer apply cleanly to the current master version of the code" could not be more spot on. We switched from TFS to Git a couple of years ago, and the ABI-breaking branch lies largely abandoned on our old TFS instance. There will be quite a bit of hand-porting involved, with the likely exception of the threading bits that were completely rewritten. We did pull in the <atomic> rewrite a few months ago, for example, and that wasn't too bad except for a few days spent to maintain the old ABI.

[jonwil]

Are there any cases of abi-breaking changes that need to be made to vcruntime, vcstartup. concrt or other closed modules or any cases where abi-breaking changes require closed modules to be recompiled to work?

[StephanTLavavej]

I recall some changes being made to vcruntime, in addition to a new "vcplatform" layer being added. I don't recall any ConcRT changes; we'll be able to drop the ConcRT link along with our XP targeting support. We'll need to rethink vcplatform as we reapply the changes to GitHub. Among other things, we clang-formatted the STL's sources in the meantime and changed other conventions, so all of the changes will need to be handled line-by-line.

[jonwil]

I thought VS 2019 dropped XP support (or are there enough users out there that still need XP support that bringing it back to VS 2019 is necessary?)

[sylveon]

Probably just would break the ABI to drop all the XP support bits

[StephanTLavavej]

It did drop XP targeting support (in the IDE, etc.) but unfortunately we can’t remove it from our DLLs, as that would damage any XP machines if the redist were to be installed there.

[jonwil]

I forgot that the 2019 dlls are also the dlls for versions of VS where the XP targeting support is still actively supported.

[TheStormN]

Hey @StephanTLavavej ,

Sorry to bother you again on this issue, but as time passes, it would be nice to get a bit of information how the things are now and where are they going. :)

So VS 17.2 LTSC was released with completed C++20 support. Also this is the second LTSC release of the 17.x series. Lots of work was done, lots of bugs were fixed, lots of new stuff was added and of that is great. My thanks to you, your team, compiler devs and everyone else dedicated to C++ ecosystem in MS!

Since we are here, I would like to know(I guess not only I), how the things are going with the vNext project(both STD library and compiler). Do you now have a bit more light, when this project can actually be started, do we really need to wait 2-3 years for VS 18.x? Can you make a new branch from 'main', where ABI stable work can continue and start using 'main' for breaking changes? I guess all the work that would not break the ABI can be backported to the 'abi-stable' branch and so on...

So anyway, these are just a few thoughts, but I would like to hear from you. :)

[StephanTLavavej]

I'm glad you like 17.2!

We haven't done any work on vNext, and currently there is no ETA for when work will start.

Can you make a new branch from 'main', where ABI stable work can continue and start using 'main' for breaking changes? I guess all the work that would not break the ABI can be backported to the 'abi-stable' branch and so on...

We tried maintaining two branches simultaneously and it was unworkable - that's a big reason why our initial vNext changes are stranded in a long-unused TFS branch.

I strongly believe that in order for vNext to work, we need a clean switchover, where new work stops flowing into the ABI-stable branch and starts flowing into the vNext branch. Perhaps the completion of C++23 will be a good time, but that's far from certain yet.

[jonwil]

The problem as I understand it is that the ABI-break needs not just STL and runtime library work but also (in order to deliver the most benefit) compiler work and with so many other things on the table (newer C++ standards, compile time improvements, workflow improvements etc) that were deemed more important, the compiler team hasn't have the time to work on the ABI-break work (which is why the plans to make VS2022 ABI-breaking were dropped).

[MikeGitb]

Won't you need at least a couple of month or longer to perform all the ABI-breaking work? Not to mention that you probably want 1-2 iterations of real-world feedback, before freezing the new ABI again. Is that really possible without having (at least for some time) two branches in parallel?

I've had to work on a bigger v1 - v2 transition only once so far and of course with no where near as many users as the STL, but what did work for us was
a) Daily merge any change from v1 to v2
b) Keep v2 in a "merge/diff friendly" state for the period of transition. E.g. large removals where achived by a simple #if 0 rather than physically removing the LOCs and we also tried to avoid shuffling code around.

Of course, maintaining two branches is strictly more work than one, but if the alternative would be much more time pressure and less chance for feedback, I'd at least consider it, as long as there is a clear goal/time frame and the switch over doesn't get pushed further indefinetly.

[StephanTLavavej]

Won't you need at least a couple of month or longer to perform all the ABI-breaking work?

I believe it would be at least a year of work.

Is that really possible without having (at least for some time) two branches in parallel?

Sure.

Note that we inherently have release branches - e.g. VS 2019 16.11.x has an internal release branch, alongside the branch for VS 2022 17.x. The question is where arbitrary development work (new features and fixes) flows into. For the STL, that is always into the latest branch, with very rare exceptions (backporting C++20 DRs to 16.11.x being the largest).

A clean switchover would simply mean that we'd declare that no new features and only critical fixes would flow into the ABI-stable branch, with all new work going into the vNext branch.

For the STL, maintaining two branches simultaneously (i.e. adding features to both) would be a massive amount of additional work(*), and we need to make major overhauls that are extremely unfriendly to diffs (and I can speak from experience, since we tried parallel branches already, in the abandoned effort).

* The only way we can keep up with Standardization is by prioritizing development throughput and avoiding wasted work - this explains a lot of our processes that might otherwise seem strange (e.g. extreme effort spent on code review to minimize effort spent on bugfixing).

[TheStormN]

@StephanTLavavej Thanks for the detailed explanations. I see the big picture now.

Perhaps the completion of C++23 will be a good time, but that's far from certain yet.

And this is where I think we are stuck in infinite recursion. Always trying to catch up with latest standards and no time to pick up the tech debts. This can go forever, if a plan is not made soon...

Perhaps take a look how other vendors keep ABI compat and still fixing stuff. For example GCC STD library is really not compatible both ways. For example, if I build something on Ubuntu 16.04, it will work on Ubuntu 20.04, but not vise versa(given that only dependency is the g++ lib). The runtime linker complains that it cannot find functions with names, which are tagged to the specific newer gcc runtime. If not enough people are available for the STD library and compiler FE, perhaps convince bosses to hire more? These are just a few thoughts, but I think we have to start thinking of something.

[MikeGitb]

A clean switchover would simply mean that we'd declare that no new features and only critical fixes would flow into the ABI-stable branch, with all new work going into the vNext branch.

Do I understand correctly that you would then not ship any new features or improvements to an ABI-stable version for at least a year or so?
Not that I would complain.

[StephanTLavavej]

@TheStormN

And this is where I think we are stuck in infinite recursion. Always trying to catch up with latest standards and no time to pick up the tech debts. This can go forever, if a plan is not made soon...

Two notes:

1. We actually address a lot of tech debt in each release - especially in the compiler. (Over the last several years, the compiler front-end "rejuvenation" project has implemented a real abstract syntax tree, allowing it to handle modern C++.) In the STL, I like to think that we're also pretty good about continuously modernizing - except as constrained by ABI.
2. We're getting better at keeping up with Standardization. Compare how long it took to complete C++11/14 (aeons), to C++17 (completed in 2019 with <charconv>), to C++20 (completed in 2021 - that is, before the DRs landed and we completed it again).

Keeping up with Standardization is not the primary reason that vNext has been delayed. It's mostly a matter of:

• Management deciding that the benefits (fixing long-standing correctness/performance issues) outweigh the transition and development costs - and it helps when customers can clearly point to vNext bugs as affecting their scenarios.
• Finding the "right time" to do so, especially for the compiler front-end. The end of the C++20 cycle wasn't the right time due to other FE team priorities (and in retrospect, the C++20 DRs would also have been inconveniently timed, so I guess we were fortunate).

@MikeGitb

Do I understand correctly that you would then not ship any new features or improvements to an ABI-stable version for at least a year or so? Not that I would complain.

Yes. To clarify: My preference for a clean switchover would be to declare that the v19-compatible libraries are permanently finished, and that no new features would flow into them (only critical bugfixes). If the switchover hypothetically happened between C++23 and C++26, the v19 toolset would remain available for "side by side" use (supporting C++23), but anyone wanting new features from the latest Standards (C++26 and beyond) would need to switch to the vNext toolset. After "completing" vNext, it would then become the new ABI-stable toolset, with features being added to it.

I would have no particular objection to the compiler deciding to add features to the v19 toolset (as it experiences ABI in a very different way from the libraries), but attempting to backport library changes continuously would be expensive and error-prone. As I mentioned, it took @CaseyCarter's exceptional skill and quite a lot of time to backport C++20 DRs to 16.11.x, and that was with relatively little source divergence (just a couple of 17.x point releases, and a few relevant compiler changes). The optimal thing to do would be to focus all of our effort into getting vNext right (since it will be our one chance to fix this stuff for probably a decade until vNextNext), and then resume keeping up with the Standardization treadmill.

(General reminder: nobody wants vNext more than I do, and I am continually pushing to make it happen. Hopefully we'll have good news to share someday.)

[MikeGitb]

To clarify: What I had in mind was not to backport anything to old stable. Rather to implement new features in old stable and merge them forward to vNext and only do abi breaking work on vNext. Also, old stable would stay the only official supported version and vNext would be hidden behind a /experimenral:abi2 flag or some such until it is "done" (and maybe the next version of VS is released).

But of course: If you can take the proper time and exclusively work on vNext that is even better.

That aaide, I know I'm repeating myself, but I want to point out again that I (and I guess many others) very much appreciate the fact that you people share your thoughts on these matters here in the open, even if they are speculative and things turn out differently.

[TheStormN]

@StephanTLavavej My apologies, I guess my last post sounded really ungrateful, underestimating all the work you've all done. I've been with the MS compiler since VS 6.0(skipping VS 2002) and saw all the good and the bad. Since project rejuvenation stared long time ago I really saw how with each year not only the products, but the company transformed from disregarding(and even hating) open-source to loving it.

The design work behind the current stable ABI was vary brave(breaking the runtime to many satellite DLLs - api-ms-win-*.dll) in order to add new functionality and keep compatible ABI, although this ended up not really great and the idea behind it was to satisfy both regular users and corporate customers and I do appreciate all of that. I also saw how quickly you've reacted to my bug report about std::function capture in lambda and fix was implemented just a few days after the reporting. So by NO means I would want to suggest that you(all) are not addressing tech depts or not hearing the community.

Now back on the main topic a bit. :) As far as I understand, keeping ABI between major releases is to allow corporate customers to make more timely migrations to the new versions and that you have tremendous positive feedback about that. However I would also like to share my years of experience in large corporations regarding upgrades. All of the ones that I've been working for are still migrating slow. For example in my current company(40k+ people) are using VS 2019 v16.9.x, because it is still supported and they are now looking forward to the next Long-Term supported version in order to avoid updating as much as they can and while the upgrade will be easier, because of the ABI compatibility(they are not going to recompile some of the libs), this does not mean that if there were an ABI break, they would reconsider. That's because of ISO policies which require only supported software to be used with or without ABI compatibility. So while in case of ABI break, the work would've been a bit more, it was not going to be avoided.

I guess my point is that freezing an ABI for 10+ years in general would lead to positive testimonials(because they've saved some time recompiling, but the time for testing the product is still the same), it is not worth it. :) I know you don't have much saying regarding the matter and if it's up to you, you will break the ABI on every major release, but perhaps you can push for the company to make a bit different surveys regarding corporations upgrading to newer version(for example breakdown of the time spent on compilation and testing). My guts tell me that you may get surprised.

[StephanTLavavej]

@MikeGitb

To clarify: What I had in mind was not to backport anything to old stable. Rather to implement new features in old stable and merge them forward to vNext and only do abi breaking work on vNext.

I see. That's effectively the same amount of work, though - we'd still have to ensure that features can work in both "universes". Some would be easy (those with few dependencies on existing code), some would be hard, but the amount of extra work would be basically independent of where the feature was originally developed.

Essentially the reason I'm so allergic to the idea of adding features to two diverging branches simultaneously is that it takes all of our effort and skill just to keep a single branch up to date with the Standard and always shipping at production quality. We have what I believe is the largest single team of Standard Library maintainers at a single company, working alongside an awesome group of contributors here, but our capacity is still finite and we have to be careful what we spend time on.

I (and I guess many others) very much appreciate the fact that you people share your thoughts on these matters here in the open, even if they are speculative and things turn out differently.

😻

---

@TheStormN

Since project rejuvenation stared long time ago I really saw how with each year not only the products, but the company transformed from disregarding(and even hating) open-source to loving it.

😻 😸

I also saw how quickly you've reacted to my bug report about std::function capture in lambda and fix was implemented just a few days after the reporting.

Yeah, that one was real interesting - JonCaves explained to me that it had always been a compiler bug, where the lambda's "secret" constructors (that the compiler uses to initially construct the object, but which should never be visible afterwards) were still visible to SFINAE, and the new changes in std::function constraints revealed this issue which had lurked for 10+ years!

For example in my current company(40k+ people) are using VS 2019 v16.9.x, because it is still supported and they are now looking forward to the next Long-Term supported version in order to avoid updating as much as they can and while the upgrade will be easier, because of the ABI compatibility(they are not going to recompile some of the libs), this does not mean that if there were an ABI break, they would reconsider.

This is very useful information, thanks for explaining. It's things like this that might help convince our bosses and boss-like entities!

perhaps you can push for the company to make a bit different surveys regarding corporations upgrading to newer version(for example breakdown of the time spent on compilation and testing). My guts tell me that you may get surprised.

Yeah, that's a good idea - we do such research from time to time, we could ask questions along those lines.

[vrubleg]

Last 10 years we had a new major Visual Studio update roughly each 2 years. VS2022 is soon 2 years. Any news or rumors on the next major update? Is Dev18 announcement right after the corner? =)

[StephanTLavavej]

@vrubleg We try to be very open about our plans for the STL in this repo, but there are a few things we can't ever comment on - unannounced releases and release dates are major examples.

[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.