Hello folks,
Maybe the smallest RFC ever, but maybe not – I’d like to bump the required MSVC version, but by a small amount: one dot release.
Currently the minimum is VS 2019 16.7. The next dot release of 16.8 removes a limitation on string literals longer than 64k characters.
(edit) @AaronBallman helpfully provided the exact release dates of the relevant versions here for reference below: [RFC] Raising minimum MSVC version by one dot release - #4 by AaronBallman
My motivation is that I’ve started some small efforts to reduce the number of dynamic relocations required to Clang and LLVM libraries, and one of the largest sources of them are pointers to string literals stored inside of large generated data structures. Some of these are helpfully using TableGen, but not all are. An effective technique is to build a single string literal that is a table and use offsets within that table. This can now often be done with constexpr and even in a quite complex case such as Switch builtin strings to use string tables by chandlerc · Pull Request #118734 · llvm/llvm-project · GitHub doesn’t seem to add too much complexity.
However, these techniques are much harder or impossible without creating long string literals. Every version of Clang and GCC seem to easily handle these, but MSVC only removed this restriction in the next patch release.
Hopefully, as a tiny patch release, this is very non-disruptive. It doesn’t seem to violate the policy around two versions being supported, etc. That said, I’m not a Windows developer, so folks, please let me know if this is a bigger deal or if I need to do any particular broad coordination here. (I’m also pretty out of the loop on LLVM upstream stuff, so please point me to anything I should be doing here and apologies.)
I have a PR prepped to update CMake and the documentation, but wanted to start here.
2 Likes
I think this is fine. You have to try pretty hard to not install the latest patch version of MSVC anyway. And since it’s still some time before the next release branch I think it’s pretty good timing.
1 Like
No objection from me. Even my ancient VS2019 install seems to be at 16.11, and our two buildbots (1, 2) appear to have just recent versions enough.
FYI for those who don’t follow MSVC releases closely:
| Version |
Release Date |
| 16.7.0 (first) |
Aug 2020 |
| 16.7.28 (latest) |
Apr 2022 |
| 16.8.0 (first) |
Nov 2020 |
| 16.8.7 (latest) |
Mar 2021 |
We explicitly document that we require the latest patch release of Visual Studio, so that means we’re bumping the date of the toolchain from Apr 2022 to Mar 2021.
Because we already have the bot coverage for this and the version bump is so small (and the version overlaps so timely), I don’t see a problem with the change.
That said, I’m going to add the potentially-breaking tag to this post to alert downstream vendors more broadly.
2 Likes
First, this is a ‘dot release’, not a ‘patch release’, right? (I assume the 3rd decimal is the ‘patch release’)?
Second, I don’t see a problem with this. If our build-bots can already handle it, and a few of our downstreams don’t cause a ruckus, I’m all in favor of updating our toolchains.
Yeah, sorry – this was just my lack of detailed understanding. @AaronBallman gave a nice, more precise and exact explanation of the actual change this involves. I’ll edit my top post to reflect his more precise statement.
Not seeing any real concerns here, I’ve sent the PR: Bump minimum MSVC version by one dot release to VS 2019 16.8 by chandlerc · Pull Request #118833 · llvm/llvm-project · GitHub
Let me know if there is anything (other than getting a review) I should wait on before landing.
Have LG from Hans, merging the PR now. Thanks all!
