STL
STL copied to clipboard
microsoft
GitHub: Create releases for VS 2019 16.5 and beyond
A snapshot of the STL's sources was taken for VS 2019 16.5, the first time that changes from microsoft/STL contributors appeared in Visual Studio. We should create a GitHub release for this historic moment. We need to:
- Verify that the commit that most closely corresponds to...
- [x] VS 2019 16.5 is b61483432979aafb6b89b245fb8e82eee7aee32f.
- [x] VS 2019 16.6 is 2b2746dd78d06493cb204e8616beec7991d72840.
- [x] VS 2019 16.7 is 0e4c6412dfbdcd87f42d0b985408264043470014.
- [x] VS 2019 16.8 is be0441cda16c2cb49d0bc3710d77912b866992a4.
- [x] VS 2019 16.9 is e604b6c2ff7e425940264858dba2bc4bfd052b55.
- [x] VS 2019 16.10 is 8eca13a3bfd44300c848bb93153cded88168aea4.
- [x] VS 2022 17.0 is a9321cfe53ea31a7e197d5d8336167d6ca3de8b6.
- [x] VS 2022 17.1 is 3c2fd04d441d46ec9d914d9cbb621a3bac96c3a5.
- [x] VS 2022 17.2 is 4bb41db3d8e7605fc03656659752f3fad4133bc0.
- [x] VS 2022 17.3 is 60decd0d829e68666b556780002c83605d748d80.
- [x] VS 2022 17.4 is af8adfa73b7433d4f902584bc1994c897297e492.
- [x] VS 2022 17.5 is c873cf01323f2f37ce3021f344d905dc84411fe3.
- [x] VS 2022 17.6 is 28a6aab88a37e5cceef1fb16045296935f6ac53b.
- [x] VS 2022 17.7 is a62109595b6d89e08172fdf4beb75a2670fe0cc9.
- [x] VS 2022 17.8 is ab600751924207014ab02f7422ee00a6843e2f0f.
- [x] VS 2022 17.9 is 900eeacbd713792e2b9d64ed198c068dc7eedd2a.
- [x] Choose a naming convention for the tag:
vs-2019-16.8. - [x] Choose a release title: VS 2019 16.8.
- [ ] Take release notes from the Changelog.
- [ ] Finish Changelogging VS 2019 16.5.
We don't expect that to be a common sync target, so making the tag verbose sounds fine to me. How about visual_studio_2019_16.5_preview2?
that sounds fine to me as well. Making the tag long like that also decreases the likelihood people will consider that yet another official product version.
Write release notes
I think we should submit a few "big deals" for the VS release notes, then the github releases thing replaces the "STL Features and Fixes" blog posts we did from time to time. Since our PM friends don't seem to like those posts anyway...
Does this mean it will be possible to pull the tag and compile something that is a functionally identical (and ABI compatible) replacement for the dll that gets shipped with the product? Or are there things (e.g. having to do with XP targeting) that would prevent it?
That is the intent. Currently you should be able to pull this repo and build something functionally identical to the "desktop" flavors.
So yes. that is the intent, and it should be possible. We will likely accept bugs if that's not possible.
The libraries shipped in visual studio are built using the same sources as appear here.
Of course there's only "P" (e.g. msvcp140) components here. vcruntime et al. are still needed for a functional program.
Hi If I remember correctly Microsoft provides stripped pdb(s) for msvcp140.dll dlls. Now, when you are open source, it would be great to see whole call stacks if you can.
Are you considering to distribute pdb files with unstripped debugging info that is linked to stl github repo?
I completely understand it may be quite complicated for you to distribute pdbs indexed with github links form Microsoft “sandboxed” build eco-system.
But I still think it might be helpful to provide us at least tag that could give us ability reindex msvcp*.pdb in internal systems with source code linking to github.
Better call stack crash reports we can repot to you so better STL you can ship.
Thank you
Palo Misik
If I remember correctly Microsoft provides stripped pdb(s) for msvcp140.dll dlls.
They should not be stripped but I wouldn't be too surprised if there's a bug somewhere that they are being stripped.
Are you considering to distribute pdb files with unstripped debugging info that is linked to stl github repo?
No, because the bits that ship in the product Visual Studio aren't derived from this repo directly. (Right now we are manually replaying any changes in here into the DevDiv tree and using the existing build / deployment system from before we went OSS there; that's why there are still msbuild scripts here).
distribute pdbs indexed with github links
That sounds like you're talking about source indexing which I believe we do not do at all at this time.
Is the intent that at some point in the future the STL bits that ship with the product will be built using this repo (or source that is a direct copy of this repo) or are there things about the way Visual Studio (and its bits including the STL) get built that prevent this from happening?
I don't think we know the answer to that yet. The highest priority is that existing Visual Studio customers' experience remains unaffected by the OSS project. If we can do that building the actual shipping bits here that would be ideal.
Any updates? It would be nice if you tag something as release having VS16.5 released.
It would be nice to be able to pull a tag from this repo and get source code that (when compiled per the relavent build instructions) produces a binary that is ABI and functionally compatible with the binaries that come with the latest version of Visual Studio 2019.
Also I'd like to ask about backward compatibility with cl.exe and its runtime. Is it possible to build the latest STL (or VS16.5 tag in the future) with older cl.exe from VS2017? 2015?
No. Old library with new compiler should work, but new library with old compiler is explicitly blocked. The compiler adds new intrinsics / behavior that we depend on all the time.
Is it possible to build the latest STL (or VS16.5 tag in the future) with older cl.exe from VS2017? 2015?
It's not supported, which answers a slightly different question than "is it possible." We aggressively remove workarounds for fixed compiler bugs from the STL to avoid choosing between coding to the lowest common denominator or working in a codebase where everything has 6 different conditionally compiled variations. We just as aggressively adopt new language features as they become available in our support compilers. So while it's possible that you could sometimes go back a compiler update or two and get it to build the current STL if you hack out the block, the result in the vast majority of such scenarios will be build failure.
That's reasonable. Thank you.
where everything has 6 different conditionally compiled variations
What are those? Static, shared, mt, md, (clr?) ...? Or do you mean something else?
(Not sure whether I asked this before)
We have now STL open sourced, but in order to use it (build it) we still need vcruntime, concrt, not speaking about winsdk/ucrt. Do you have any plans on open sourcing some of the dependencies of STL (C++/compiler parts, maybe ucrt?)? Is it possible to upload not-open-sourced parts like vcruntime/concrt into some package mananer? Main concent is about redistribution rules.
What about building STL with clang? Do I still need concrt (prob. yes), vcruntime?
For example, user installed winsdk, ucrt from MS redistributable packages - no license violations. Next, we install STL from C++ PM - it's ok now with APLv2. What about missing parts? Do user need to install VS or Build Tools with vcruntime/other support libs?
Please submit questions as separate issues - we have a Question issue template for this very purpose. As a special exception, I'll answer your questions here. (For the original issue here, we still need to create releases - I am slowly digesting some Changelog entries that we hadn't recorded in the wiki. C++20 PRs are taking priority.)
What are those?
I believe Casey meant having code sections with workarounds for bugs in VS 2017 15.4, VS 2019 16.1, VS 2019 16.3, etc. Supporting anything other than the latest compilers would melt our brains.
We have no plans to open-source the compiler and UCRT. We're looking into open-sourcing VCRuntime/VCStartup but there are no concrete plans to share at this time.
While we support Clang as a first-class citizen from a user perspective, we don't support using Clang to build the STL at this time. That could be interesting to look into (I would be interested in using Clang's strict warnings and conformance to cleanse our separately compiled sources), but supporting it permanently as an option seems like a maintenance and testing burden. If it were simple enough, it might be possible.
In particular, you need support for SEH (/EHa) to build the STL and clang-cl does not implement SEH.
I have not yet had a chance to finish filling out the 16.5 changelog which is what's holding this up. We need to prioritize C++20 feature work so this may need to be deferred until early next year.
@glevner No - our GitHub history is strictly linear, but 16.11.14 was a highly nonlinear backport where @CaseyCarter merged over 100 commits to an MSVC-internal release branch. We very briefly considered creating a similar backport branch on GitHub, but it would have been a significant amount of additional work for very little benefit.
Friendly question: Any updates on this? It would be nice if you could at least create the releases, and fill in the release notes later. Thanks!
I have been severely overloaded, sorry. I wanted to have full release notes when I create the tags.
Any updates here? Looking into using this as part of some code generation, but currently have to use this issue instead of Git tags (which this issue fundamentally represents)
If release notes is the only blocker then do note that you can create a release for an existing tag i.e. backdate the release notes when you have the availability to do so
IMHO tags can be helpful when analyzing errors reported with Godbolt.
