microsoft
vNext: Make the abi-breaking-changes branch available on GitHub
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)
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.
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)
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>
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.
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?
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.
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?)
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.
I forgot that the 2019 dlls are also the dlls for versions of VS where the XP targeting support is still actively supported.
Would it make sense to create an entirely separate branch here on github that is just a copy-paste version of you internal TFS branch just to give it exposure to the community (there are tools that would preserve history, so you can actually see the diffs that where applied relative to the old master and not just compared to the current one). The actual integration work could then either be done in yet another branch, or by adding the changes directly into master but hidden behind appropriate #ifdefs.
Creating a separate branch also creates many process challenges. You'd probably only want breaking changes to go into this STL Next branch and all other changes to go to master. For every change to master, you need to cherry-pick the changes and merge them into the STL Next branch which can be problematic. Just before master is released you probably want to lock it down and only accept high priority bug fixes to it as final testing is done. At this point, the STL Next branch can take non-breaking changes. When master is released you now have a problem of merging STL Next back into master. There are many ways to deal with the myriad problems with managing multiple branches but all of them have many pain points. And not to mention the issue associated with managing separate CI systems for multiple branches. It's not just a matter of creating an STL Next branch and going wild on it. That's a recipe for disaster.
@MikeGitb
Would it make sense to create an entirely separate branch here on github that is just a copy-paste version of you internal TFS branch just to give it exposure to the community (there are tools that would preserve history, so you can actually see the diffs that where applied relative to the old master and not just compared to the current one).
Unfortunately, that will not be possible. We spent several months cleaning up our product and test code for public release (notably, overhauling all of the copyright/license banners, and properly handling all non-Microsoft-written code). That's why this repo's GitHub history begins in September 2019. The vNext TFS branch predates all of that work, so we can't publicly share it as-is.
The history is also a complete mess, partially due to how difficult merging was before git. We don't have a clean "rebased" record of the changes relative to where vNext diverged from v19. We need to extract the parts we want so we can have a clean record.
@SunnyWar
Creating a separate branch also creates many process challenges.
Yes, we will definitely need to figure out how to handle vNext logistically. It would certainly be simplest if v19 development stopped (except for critical fixes) and vNext development started with a purely linear history, but we may end up needing to merge features from v19 to vNext periodically.
@SunnyWar: This wasn't meant as a suggestion to have two parallel development branches. I was just asking if existing work could be made visible to the community, which could then help with the integration process in whatever way the dev team seems fit. I'm not surprised that the code is not fit for the public, but I thought I'd ask.
Working on a new major release while still supporting the old once is certainly not a new or uncommon problem, so there exist a lot of existing practice around this. Personally I'd develop vNext on master when and if that actually becomes a thing and keep a branch for v19, that receives bugfixes and backports via cherry picking, when possible, but is not otherwise kept in sync with master one way or the other.
Of course, I'm not involved in this library and know far too little about the development and testing process of msvc (or Microsoft for that matter) to know if that is actually a sensible strategy here.
Are there any updates on this or plans? Some of the bugs that are tagged vNext are really showstoppers in some cases. Perhaps Visual Studio 2021 with binary incompatible STL to VS2015-2019?
We're currently planning to finish C++20 (hopefully in 2020) before working on vNext (hopefully in H1 2021).
@StephanTLavavej Thanks for the info! But perhaps it would be a nice idea to publish the vNext branch here, even now, so at least the community will start solving stuff, while you are working on C++20? :)
The issues with that are:
- The vNext changes we accumulated a few years ago are stranded in Team Foundation Version Control (before the MSVC-internal repo moved to git) and the codebase has significantly diverged since then, so we'll need to hand-port all of those changes.
- The STL maintainer team has literally no capacity to review vNext changes right now. Any time spent on that is time not spent on C++20.
The community is absolutely welcome to start working on binary-incompatible overhauls (e.g. regex would be amazing), but we really can't review them or provide more than the most superficial guidance until next year.
Ah, I see, very unfortunate... Buy anyway, thanks for the honest update and keep up the good work! We've waited 5 years, so we can wait a few more months. :)
At the same time it would be quite valuable to know what you already did.
I think that there is a lot of interest in the community to work on this so the question is whether it is wise for a maintainer to spend a week porting some feature when he could review what a contributor did porting the same feature.
Maybe once there is some more time to breath for you it would make sense to create a vNext project with the different things you already did and the things you plan. I believe letting the community start beforehand is much better than just locking yourself into a 6 month window
Yeah, we can do that once one or more maintainers are available. From memory, the work we accumulated and will need to port is:
- Complete overhaul of our threading machinery by @BillyONeal. (This was accompanied by an overhaul of our atomic machinery, but I believe most of that was backported already; there is a bit remaining though.)
- I overhauled the container iterators, including changing their IDL=2 chaining from singly-linked to doubly-linked, and templatizing iterators on constness and checking (decreasing verbosity and avoiding bugs involving inheritance). I didn't get to
vector<bool>anddequein time. - @amyw-msft refactored our exported classes into a flat C interface and fixed a bunch of iostreams stuff.
- ~~Amy also refactored our OS detection/polyfill logic into a "vcplatform" layer but it is unclear whether we will need/want to port that, given XP and presumably Vista support removal.~~
- :x: We've removed (nearly all traces of) XP/Vista, and are about to remove Win7 and hopefully Win8/8.1 in Dev18. The OS polyfill machinery has been dramatically simplified to the point where vcplatform would be more complicated, so we don't need it anymore.
- Removal of
/clr:pure. - I think we removed
<hash_set>and<hash_map>.
More things that I would like to do, that haven't been done yet:
- Eradicating
/Zc:wchar_t- - Consolidating all satellite DLLs back into the main DLL
- Fixing all of the noted
TRANSITION, ABIissues throughout the codebase - Remove
<experimental/filesystem>and ideally the rest of the experimental machinery that has been superseded - Doing something about
<regex> - Cleaning up
<random>and its accumulated layers of TR1 machinery - Overhauling
unordered_meow - Overhauling
deque - Overhauling
tuple- specifically implementing compression and eliminating the recursive inheritance - Overhauling the floating-point code in iostreams - I can finally see how wrong it is
- ~~I would like to deprecate
<cvt/meow>before v19 ends so we can remove it in vNext~~- :white_check_mark: Removed by #4458!
- Dropping IDL=1
- Figuring out a "no exceptions" story and cleaning out the weirdness of
_HAS_EXCEPTIONS=0.
It would be amazing if we could drop C++14 mode but it would also be amazing if I got a pony and a unicorn.
Just for me, is it possible that we support concepts in all language modes once EDG supports them (Looking at tuple especially)
We'll be able to use concepts in C++20 mode, but not in C++14/17 mode - i.e. it's not like if constexpr or explicit(bool).
Hey again @StephanTLavavej
Time passed, C++20 implementation of MS STL is completed(still waiting for a few fixes from WG, but nothing major). Do you have more clear idea when the work on vNext can be started? :)
@TheStormN Unfortunately, while we originally hoped that we could finish C++20 and switch to vNext, the compiler front-end team is currently too busy to work on vNext changes. :crying_cat_face: While it isn't absolutely required for the compiler to break ABI at the same time as the libraries, it would be sad if only the libraries used this once-in-a-decade opportunity without simultaneous FE changes to fix the empty base class optimization, improve RTTI layout, etc. At this time we don't have an ETA for when the FE and STL will be able to start vNext - I hope it'll be the Dev18 cycle (i.e. next major version after VS 2022) but no guarantees.
I seem to recall statements in the past that the next release of VS after VS 2019 was going to be an ABI breaking release. What happened to that?
- I hope it'll be the Dev18 cycle (i.e. next major version after VS 2022) but no guarantees.
:(
And here I thought this was only about delaying the start for a couple of minor releases. Not a whole nother VS cycle.
@jonwil Long ago, we originally hoped that vNext would be ready for production at the same time as 17.0, but then it became clear that finishing C++20 was going to require a ton of work from both contributors and maintainers so we'd be lucky to reach completeness in 16.10 - which we did! So until recently, we hoped that we'd be able to start vNext now, and have it ready for release after a few updates of Dev17 / VS 2022. What happened is that the FE team had to commit to too many high-priority tasks to have capacity for vNext. I know it's disappointing news, and I am :crying_cat_face: to relay it, as I want vNext more than anyone - I'm the only current maintainer who worked on the STL during the break-ABI-every-release era (which was as glorious for development as it was problematic for customers). However, because plans have a tendency to change, if you look at our previous statements you should find that they were all expressed as hopes/expectations and not promises. We try to be open about our tentative plans for the future, while also trying really hard not to promise anything that isn't certain.
@MikeGitb It's possible that things will change (e.g. some other project is deferred or cut) and we'll be able to start vNext some time in the middle of the Dev17 cycle - I don't think it's likely at all, but it's possible. It's also possible that we might decide to do a library-only vNext release - again, low probability, but I would start arguing for that if it looks like the FE won't ever have the bandwidth for the foreseeable future.
In all fairness - while there are various ABI-related things I'd love to see fixed/improved as soon as possible, I couldn't even begin to quantify how much of a impact this would make for day to day work. Especially compared to other improvement X that probably don't require ABI breaks.