Raise the minimum Visual Studio version to VS2019

[RKSimon]

Summary

As raised here: https://lists.llvm.org/pipermail/llvm-dev/2021-November/153881.html

Now that VS2022 is on general release, LLVM is expected to build on VS2017, VS2019 and VS2022, which is proving hazardous to maintain due to changes in behaviour including preprocessor and constexpr changes. Plus of the few developers that work with VS, many have already moved to VS2019/22.

This patch proposes to raise the minimum supported version to VS2019 (16.x) - I've made the hard limit 16.0 or later, with the soft limit VS2019 16.7 - older versions of VS2019 are "allowed" (at your own risk) via the LLVM_FORCE_USE_OLD_TOOLCHAIN cmake flag.

[jhenderson]

clang/docs/UsersManual.rst

3660

Maybe make this VS2022 instead, to help it last longer?

llvm/docs/GettingStarted.rst

275–276

Perhaps add "or Visual Studio 2022" or similar?

llvm/include/llvm/Support/Compiler.h

103–106

Does this comment need changing?

[RKSimon]

llvm/include/llvm/Support/Compiler.h

103–106

An even bigger question is - can we get rid of the LLVM_HAS_RVALUE_REFERENCE_THIS define entirely now? Either as part of this patch or as a followup

[RKSimon]

address comments

[jhenderson]

No more comments from me (apart from one minor nit). This should definitely get someone with more familiarity with how these things are configured to take a look though.

clang/docs/UsersManual.rst

3660

I think the missing space should be fixed to :)

llvm/include/llvm/Support/Compiler.h

103–106

Yeah, another patch entirely to sort this would be fine.

[RKSimon]

llvm/include/llvm/Support/Compiler.h

103–106

I'll add a FIXME to this patch

[RKSimon]

rebase and add FIXME

[aaron.ballman]

Have you checked whether there are any bots in the lab that will need to be updated?

clang/docs/UsersManual.rst

3660

+1 to the missing space.

llvm/cmake/modules/CheckCompilerVersion.cmake

17–18

I'm a bit less certain that this is reasonable. 16.11.0 is from August 2021, which seems incredibly new for giving soft errors on.

llvm/include/llvm/Support/Compiler.h

103–106

+1; FWIW, the last time we tried to get rid of this, the only thing we could realistically do was remove it and see how the bots/community reacted. Doing that in a follow-up patch seems like a good idea to me.

[RKSimon]

Have you checked whether there are any bots in the lab that will need to be updated?

I did find a number of bots that I think need addressing, I am intending to privately email the owners but I haven't done that yet - @rnk maintains the sanitizer-windows and windows-gcebot2 machines, but there are others.

clang/docs/UsersManual.rst

3660

This one is confusing - it isn't in my local diff, the raw diff, or if I reapply the raw diff - it looks to have just appeared when you quote it in phab comments?

llvm/cmake/modules/CheckCompilerVersion.cmake

17–18

Our docs do say the latest update of the compiler, but I take your point.

16.10 (same _MSC_VER) was released in May 2021
https://docs.microsoft.com/en-us/visualstudio/install/visual-studio-build-numbers-and-release-dates?view=vs-2019

If we want something a year old, 16.8 + 16.9 (1928) is about right.

[jhenderson]

clang/docs/UsersManual.rst

3660

The fact that the space is missing? It's missing in the current repo too.

[aaron.ballman]

In D114639#3158401, @RKSimon wrote:

Have you checked whether there are any bots in the lab that will need to be updated?

I did find a number of bots that I think need addressing, I am intending to privately email the owners but I haven't done that yet - @rnk maintains the sanitizer-windows and windows-gcebot2 machines, but there are others.

Thanks! I think we'll need the bot situation sorted out before we land this, otherwise we'll have bots red and failing to report newly introduced regressions from other patches. (Hopefully we'll replace the bots with ones that test newer VS configurations rather than lose the coverage entirely.)

llvm/cmake/modules/CheckCompilerVersion.cmake

17–18

16.7 (1927) would also be quite reasonable (Aug 2020). I don't have a strong preference for 16.7 vs 16.8, so I took a look at the release notes. 16.8 added support for newer C++ features, but not ones we care about consuming in our code base (coroutines, concepts, <ranges>, some STL improvements, etc), so I think we'd be fine with 16.7 if we wanted to be more conservative on the window for the soft error.

[Meinersbur]

clang/docs/UsersManual.rst

3660

It works with and without the space, like -GNinja and -G Ninja both work.

[compnerd]

clang/docs/UsersManual.rst

3660

It would be nice to mention the CMake minimum version. I think that you need 3.22 or newer for the 2022 generator/toolset definition.

[mehdi_amini]

In D114639#3158401, @RKSimon wrote:

Have you checked whether there are any bots in the lab that will need to be updated?

I did find a number of bots that I think need addressing, I am intending to privately email the owners but I haven't done that yet - @rnk maintains the sanitizer-windows and windows-gcebot2 machines, but there are others.

This bot as well: https://lab.llvm.org/buildbot/#/builders/13 ; adding @stella.stamenova here.

[stella.stamenova]

In D114639#3160031, @mehdi_amini wrote:

In D114639#3158401, @RKSimon wrote:

Have you checked whether there are any bots in the lab that will need to be updated?

I did find a number of bots that I think need addressing, I am intending to privately email the owners but I haven't done that yet - @rnk maintains the sanitizer-windows and windows-gcebot2 machines, but there are others.

This bot as well: https://lab.llvm.org/buildbot/#/builders/13 ; adding @stella.stamenova here.

The mlir and lldb windows bots will both need to be updated to 2019/2022. We haven't been building with 2022, so I am not sure how stable the builds will be if we moved to it (though I hope it just works). We can plan to update both bots to use 2019/2022 this week before our whole teams goes on vacation.

clang/docs/UsersManual.rst

3660

I think it makes more sense to make it 2019 because I expect most people to still be using 2019 and it's convenient to have instructions that just work. Maybe add both?

3660

It works with or without the space, but it reads better with the space.

[jhenderson]

Re. the bots: I'd hope we'd have at least some bots using VS2019 rather than all rushing to VS2022. There's nothing worse than claiming to support a minimum version of something and then not actually supporting it...! Also internally, we are switching to a default of VS2019, not direct to VS2022, so having upstream coverage there would be useful to avoid downstream breakages that are actually upstream problems - we're working on adding our own Windows build bot, but I don't think it's there yet.

clang/docs/UsersManual.rst

3660

No objections either way.

3660

We should probably drop the space issue: I noticed further down that it doesn't have a space in either for e.g. Ninja. Don't mind either way though.

[RKSimon]

Thanks - I think all the MSVC bot admins are now on this patch, so I can avoid writing yet another email!

[erichkeane]

IMO, if we're updating the MSVC versions, we should do the same for the GCC/Clang/AppleClang versions too. For example, GCC 5.1 is from 2015, and Clang 3.5 is from 2014.

[aaron.ballman]

In D114639#3161303, @erichkeane wrote:

IMO, if we're updating the MSVC versions, we should do the same for the GCC/Clang/AppleClang versions too. For example, GCC 5.1 is from 2015, and Clang 3.5 is from 2014.

I'd be in favor of that; we could even see if we're ready to allow C++17 in the code base (which would be a pretty nice win for if init statements alone). However, it's also a bit orthogonal to this particular patch. Do you (or someone else) want to start an RFC?

[erichkeane]

In D114639#3161362, @aaron.ballman wrote:

In D114639#3161303, @erichkeane wrote:

IMO, if we're updating the MSVC versions, we should do the same for the GCC/Clang/AppleClang versions too. For example, GCC 5.1 is from 2015, and Clang 3.5 is from 2014.

I'd be in favor of that; we could even see if we're ready to allow C++17 in the code base (which would be a pretty nice win for if init statements alone). However, it's also a bit orthogonal to this particular patch. Do you (or someone else) want to start an RFC?

I believe the C++17 RFC was already on LLVM-dev last I saw?

That said, I commented because we typically try to update the 'minimum versions' in lockstep best we can. Bumping these versions is particularly arduous, so I'd be against trying to do it piece-meal like this, particularly as we're updating the NEWEST requirement (that is, VS2017 is newer than Clang 3.5/GCC5.1!).

Also note that we have a 'policy' for bumping versions: https://llvm.org/docs/DeveloperPolicy.html#toolchain

(From the looks of it, I think we ARE following the policy, but others should take a look).

[aaron.ballman]

In D114639#3161440, @erichkeane wrote:

In D114639#3161362, @aaron.ballman wrote:

In D114639#3161303, @erichkeane wrote:

IMO, if we're updating the MSVC versions, we should do the same for the GCC/Clang/AppleClang versions too. For example, GCC 5.1 is from 2015, and Clang 3.5 is from 2014.

I'd be in favor of that; we could even see if we're ready to allow C++17 in the code base (which would be a pretty nice win for if init statements alone). However, it's also a bit orthogonal to this particular patch. Do you (or someone else) want to start an RFC?

I believe the C++17 RFC was already on LLVM-dev last I saw?

Ah, I had missed that, thanks!

That said, I commented because we typically try to update the 'minimum versions' in lockstep best we can. Bumping these versions is particularly arduous, so I'd be against trying to do it piece-meal like this, particularly as we're updating the NEWEST requirement (that is, VS2017 is newer than Clang 3.5/GCC5.1!).

Fair point, thanks!

[erichkeane]

See: https://lists.llvm.org/pipermail/llvm-dev/2021-November/153882.html for what I was thinking of.

[mehdi_amini]

In D114639#3161303, @erichkeane wrote:

IMO, if we're updating the MSVC versions, we should do the same for the GCC/Clang/AppleClang versions too. For example, GCC 5.1 is from 2015, and Clang 3.5 is from 2014.

We've always handled MSVC update separately I believe, we can't just take the "last two version of MSVC" guideline and update every compiler each time.
(I'm not against updating our toolchain to support c++17, but that's orthogonal to the MSVC-specific update)

[RKSimon]

In D114639#3162000, @mehdi_amini wrote:

In D114639#3161303, @erichkeane wrote:

IMO, if we're updating the MSVC versions, we should do the same for the GCC/Clang/AppleClang versions too. For example, GCC 5.1 is from 2015, and Clang 3.5 is from 2014.

We've always handled MSVC update separately I believe, we can't just take the "last two version of MSVC" guideline and update every compiler each time.
(I'm not against updating our toolchain to support c++17, but that's orthogonal to the MSVC-specific update)

I recently started a C++17 conversation here, but I agree its orthogonal to the VS version bump: https://lists.llvm.org/pipermail/llvm-dev/2021-November/153882.html

[erichkeane]

In D114639#3162032, @RKSimon wrote:

In D114639#3162000, @mehdi_amini wrote:

In D114639#3161303, @erichkeane wrote:

IMO, if we're updating the MSVC versions, we should do the same for the GCC/Clang/AppleClang versions too. For example, GCC 5.1 is from 2015, and Clang 3.5 is from 2014.

We've always handled MSVC update separately I believe, we can't just take the "last two version of MSVC" guideline and update every compiler each time.

My understanding is this would only be the ~3rd time we've done this. The last time we did this, we did them all together.

(I'm not against updating our toolchain to support c++17, but that's orthogonal to the MSVC-specific update)

I recently started a C++17 conversation here, but I agree its orthogonal to the VS version bump: https://lists.llvm.org/pipermail/llvm-dev/2021-November/153882.html

I also am not particularly 'interested' in the C++17 conversation here. My bigger concern is that the last time we did the version bumps (which @jfb and I lead), there was significant interest to minimize the changes to the toolchains across platforms, which was a significant motivator to change them all at once the last time. If there is sufficient justification here to update based on the 'last 2 releases', I'd strongly suspect/believe there are similar justifications for the other two, of which C++17 is just one.

[mehdi_amini]

In D114639#3162069, @erichkeane wrote:

In D114639#3162032, @RKSimon wrote:

In D114639#3162000, @mehdi_amini wrote:

In D114639#3161303, @erichkeane wrote:

IMO, if we're updating the MSVC versions, we should do the same for the GCC/Clang/AppleClang versions too. For example, GCC 5.1 is from 2015, and Clang 3.5 is from 2014.

We've always handled MSVC update separately I believe, we can't just take the "last two version of MSVC" guideline and update every compiler each time.

My understanding is this would only be the ~3rd time we've done this. The last time we did this, we did them all together.

Right, but last time we did the motivation was specifically to get to c++14, while here the motivation is to drop an old MSVC according to the MSVC-specific support we intend to provide.

[erichkeane]

In D114639#3162133, @mehdi_amini wrote:

In D114639#3162069, @erichkeane wrote:

In D114639#3162032, @RKSimon wrote:

In D114639#3162000, @mehdi_amini wrote:

In D114639#3161303, @erichkeane wrote:

IMO, if we're updating the MSVC versions, we should do the same for the GCC/Clang/AppleClang versions too. For example, GCC 5.1 is from 2015, and Clang 3.5 is from 2014.

We've always handled MSVC update separately I believe, we can't just take the "last two version of MSVC" guideline and update every compiler each time.

My understanding is this would only be the ~3rd time we've done this. The last time we did this, we did them all together.

Right, but last time we did the motivation was specifically to get to c++14, while here the motivation is to drop an old MSVC according to the MSVC-specific support we intend to provide.

My memory is that that was _A_ motivation, not the only one. There were quite a few GCC bugs that we were getting away from as well that was my primary justification for pushing it at the time, though the C++14 motivation was ALSO tempting/appreciated.

[mehdi_amini]

In D114639#3162141, @erichkeane wrote:

Right, but last time we did the motivation was specifically to get to c++14, while here the motivation is to drop an old MSVC according to the MSVC-specific support we intend to provide.

My memory is that that was _A_ motivation, not the only one. There were quite a few GCC bugs that we were getting away from as well that was my primary justification for pushing it at the time, though the C++14 motivation was ALSO tempting/appreciated.

I'm fairly sure that at least JF who pushed for it was motivated by C++14, here is the RFC: https://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html
The update of toolchain has always historically been measured by the amount of features we get from the update, in particular while compilers were getting support for new standard feature during C++11 adoption it was really a game of matching the various compiler, looks at potential updates and what this would enable. Though I agree that we're somehow frequently working around issues specific to gcc-5 (I'd say my gcc-5.4 bot breaks once a week on average), and migrating from old toolchains can have value on its own.

[erichkeane]

In D114639#3162157, @mehdi_amini wrote:

In D114639#3162141, @erichkeane wrote:

Right, but last time we did the motivation was specifically to get to c++14, while here the motivation is to drop an old MSVC according to the MSVC-specific support we intend to provide.

My memory is that that was _A_ motivation, not the only one. There were quite a few GCC bugs that we were getting away from as well that was my primary justification for pushing it at the time, though the C++14 motivation was ALSO tempting/appreciated.

I'm fairly sure that at least JF who pushed for it was motivated by C++14, here is the RFC: https://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html
The update of toolchain has always historically been measured by the amount of features we get from the update, in particular while compilers were getting support for new standard feature during C++11 adoption it was really a game of matching the various compiler, looks at potential updates and what this would enable. Though I agree that we're somehow frequently working around issues specific to gcc-5 (I'd say my gcc-5.4 bot breaks once a week on average), and migrating from old toolchains can have value on its own.

Note that the above link was the LAST RFC, after JF and I had spent about 8 months trying to update, part of which required https://reviews.llvm.org/rG6e69db5a2dfe8cf4658654714c506422e31a19a2 to happen. At least in our private discussions, JF stated frustration at working around old Clang bugs.

[RKSimon]

Changed cmake example back to VS2019

Added note for minimum cmake version necessary for VS2022

Updated the soft version limit to: _MSC_VER == 1927 MSVC++ 14.27 Visual Studio 2019 Version 16.7

[RKSimon]

In D114639#3162157, @mehdi_amini wrote:

In D114639#3162141, @erichkeane wrote:

Right, but last time we did the motivation was specifically to get to c++14, while here the motivation is to drop an old MSVC according to the MSVC-specific support we intend to provide.

My memory is that that was _A_ motivation, not the only one. There were quite a few GCC bugs that we were getting away from as well that was my primary justification for pushing it at the time, though the C++14 motivation was ALSO tempting/appreciated.

I'm fairly sure that at least JF who pushed for it was motivated by C++14, here is the RFC: https://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html
The update of toolchain has always historically been measured by the amount of features we get from the update, in particular while compilers were getting support for new standard feature during C++11 adoption it was really a game of matching the various compiler, looks at potential updates and what this would enable. Though I agree that we're somehow frequently working around issues specific to gcc-5 (I'd say my gcc-5.4 bot breaks once a week on average), and migrating from old toolchains can have value on its own.

I'd be happy to coordinate with others if they can create patches for the respective compiler bumps, but my ability to test the many permutations of linux distros + gcc is quite limited (currently x64 ubuntu 18.04 desktop + ubuntu 20.04 wsl2) and I don't use apple hardware at all.

I still don't see a need for them to be updated in lock step, especially for Visual Studio which tends to be quite different from other toolchains, but I can see the use of the bumps occurring within the same release version of llvm if its feasible.

If we aimed to bump gcc/clang as well, would we still be in a position to get this done in plenty of time for the next release branch? I have fears that some buildbots often take many months to be updated.

[Meinersbur]

ping?

@erichkeane Since you are pushing for upgrade the gcc/clang requirement as well, would you take care of that?

[vitalybuka]

I still don't see a need for them to be updated in lock step, especially for Visual Studio which tends to be quite different from other toolchains, but I can see the use of the bumps occurring within the same release version of llvm if its feasible.

It's better to be in separate patches.

[erichkeane]

In D114639#3183244, @Meinersbur wrote:

ping?

@erichkeane Since you are pushing for upgrade the gcc/clang requirement as well, would you take care of that?

I was looking into the patch to do so, but I don't have a good idea what I should update the GCC/Clang/AppleClang requirements TO. I thought I saw someone at one point suggest GCC6/clang6, but I can't find that anymore, did I just imagine it?

I presume any such patch would have similar issues with buildbots unfortunately.

That said;
My understanding is that updating the GCC/Clang minimum versions requires altering our 'minimum platform' significantly (since you cannot ship a dynamically linked version of clang to a system with an older stdlibc++ version than you built it with), and thus would be more controversial than this patch (where updating the C++ runtime version on a system is a much lower barrier to run).

Because of that, and because my concern on the RFC seems to be mine alone, I see no reason to have my concerns 'block' this patch as it is. Additionally, since the RFC to move us to C++17 didn't seem to gain any traction, I'd presume the appetite for changing the linux/apple toolchain doesn't seem to be there.

TL;DR: Don't block this on my concerns.

[RKSimon]

@rnk @stella.stamenova How long do you think it will be before you can update your buildbots to VS2019 or VS2022 please?

[stella.stamenova]

In D114639#3191752, @RKSimon wrote:

@rnk @stella.stamenova How long do you think it will be before you can update your buildbots to VS2019 or VS2022 please?

The mlir buildbot was updated already. The lldb buildbot will be done this week - there's a test change that needs to happen in lldb before we can update the buildbot. I'll let you know once it's done.

[stella.stamenova]

In D114639#3192823, @stella.stamenova wrote:

In D114639#3191752, @RKSimon wrote:

@rnk @stella.stamenova How long do you think it will be before you can update your buildbots to VS2019 or VS2022 please?

The mlir buildbot was updated already. The lldb buildbot will be done this week - there's a test change that needs to happen in lldb before we can update the buildbot. I'll let you know once it's done.

I am declaring victory for both the mlir and lldb buildbots.

[RKSimon]

@rnk I'm not certain but I think the only buildbot still using VS2017 is windows-gcebot2 ?

[rnk]

In D114639#3199458, @RKSimon wrote:

@rnk I'm not certain but I think the only buildbot still using VS2017 is windows-gcebot2 ?

Yes, it probably uses VS2017, and probably also the sanitizer-windows bot as well:
https://lab.llvm.org/buildbot/#/builders/sanitizer-windows
https://lab.llvm.org/buildbot/#/builders/clang-x64-windows-msvc

I'm going to delegate this task, so give me some time to get to it.

[vitalybuka]

In D114639#3228704, @rnk wrote:

In D114639#3199458, @RKSimon wrote:

@rnk I'm not certain but I think the only buildbot still using VS2017 is windows-gcebot2 ?

Yes, it probably uses VS2017, and probably also the sanitizer-windows bot as well:
https://lab.llvm.org/buildbot/#/builders/sanitizer-windows
https://lab.llvm.org/buildbot/#/builders/clang-x64-windows-msvc

I'm going to delegate this task, so give me some time to get to it.

Would you like me to do that?

[vitalybuka]

https://lab.llvm.org/buildbot/#/builders/sanitizer-windows
https://lab.llvm.org/buildbot/#/builders/clang-x64-windows-msvc

Actually these were already on VS2019, version 16.8, so I only updated them both to 16.11.

[stella.stamenova]

Can we update the lldb instructions as part of this change to also point to VS2019? Alternatively, I can send a separate change for that.

[RKSimon]

In D114639#3273761, @stella.stamenova wrote:

Can we update the lldb instructions as part of this change to also point to VS2019? Alternatively, I can send a separate change for that.

I'll add it to this patch - are people happy for me to get this in before the 14.x branch?

[stella.stamenova]

In D114639#3273831, @RKSimon wrote:

In D114639#3273761, @stella.stamenova wrote:

Can we update the lldb instructions as part of this change to also point to VS2019? Alternatively, I can send a separate change for that.

I'll add it to this patch - are people happy for me to get this in before the 14.x branch?

Sounds good to me.

[RKSimon]

update lldb docs as well

[aaron.ballman]

In D114639#3273831, @RKSimon wrote:

In D114639#3273761, @stella.stamenova wrote:

Can we update the lldb instructions as part of this change to also point to VS2019? Alternatively, I can send a separate change for that.

I'll add it to this patch - are people happy for me to get this in before the 14.x branch?

I'm fine with that (we can always roll it back in the branch if it turns out to be a burden).

[stella.stamenova]

lldb/docs/resources/build.rst

303

This line should change a bit more. For VS2019, it also needs to include -A 64 like so: cmake -G "Visual Studio 16 2019" -A x64 -T host=x64.

[RKSimon]

update lldb cmake command

[stella.stamenova]

lldb/docs/resources/build.rst

303

You accidentally added -T host=x64 twice now. It can be included with or without the space, but it's only needed once.

[RKSimon]

fix cut+paste typo

[RKSimon]

@stella.stamenova It looks like the mlir-windows buildbot is still using VS2017:

CMake Error at cmake/modules/CheckCompilerVersion.cmake:39 (message):
  Host Visual Studio version must be at least 19.20, your version is
  19.16.27045.0.

Are you able to make the fix or would you prefer I revert for now?

[cfe-commits]

I will take care of it today. The bot does have vs2019 installed and it should be picking up latest VS (and it was when I updated it), so there is an easy fix (remove 2017) and then I can investigate why it stopped picking up latest.

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Simon Pilgrim via Phabricator <[e-mail]>
Sent: Saturday, January 29, 2022 3:12:52 AM
To: [e-mail] <[e-mail]>; Reid Kleckner <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Stella Stamenova <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Saleem Abdulrasool <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [EXTERNAL] [PATCH] D114639: Raise the minimum Visual Studio version to VS2019

RKSimon added a comment.

@stella.stamenova It looks like the mlir-windows buildbot is still using VS2017:

CMake Error at cmake/modules/CheckCompilerVersion.cmake:39 (message):
  Host Visual Studio version must be at least 19.20, your version is
  19.16.27045.0.

Are you able to make the fix or would you prefer I revert for now?

Repository:

rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD114639%2Fnew%2F&data=04%7C01%7Cstilis%40microsoft.com%7C1299827a2cee41cb745b08d9e3184ba9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637790515814400729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WccQ1%2B3T0IE2c%2BrjkWNmZIFZFsQaaGq6NIM8gpduOpY%3D&reserved=0

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD114639&amp;data=04%7C01%7Cstilis%40microsoft.com%7C1299827a2cee41cb745b08d9e3184ba9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637790515814400729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=eymjF3kMlfwwx8%2Bf0B10dxYWaW%2BYkSuvmoWCCBuR2YE%3D&amp;reserved=0

• msg-24181-77.txt160 BDownload

[RKSimon]

mlir-windows buildbot looks to be green now - thanks!

clang/docs/ClangFormatStyleOptions.rst

**BasedOnStyle** (``String``)
   * ``Mozilla``
     A style complying with `Mozilla's style guide
     <https://firefox-source-docs.mozilla.org/code-quality/coding-style/index.html>`_
   * ``WebKit``
     A style complying with `WebKit's style guide
     <https://www.webkit.org/coding/coding-style.html>`_
   * ``Microsoft``
     A style complying with `Microsoft's style guide
-    <https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference?view=vs-2017>`_
+    <https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference>`_
   * ``GNU``
     A style complying with the `GNU coding standards
     <https://www.gnu.org/prep/standards/standards.html>`_
   * ``InheritParentConfig``
     Not a real style, but allows to use the ``.clang-format`` file from the
     parent directory (or its parent if there is none). If there is no parent
     file found it falls back to the ``fallback`` style, and applies the changes
     to that.

clang/docs/UsersManual.rst

 
 It's also possible to point MSBuild at clang-cl without changing toolset by
 passing ``/p:CLToolPath=c:\llvm\bin /p:CLToolExe=clang-cl.exe``.
 
 When using CMake and the Visual Studio generators, the toolset can be set with the ``-T`` flag:
 
   ::
 
-    cmake -G"Visual Studio 15 2017" -T LLVM ..
+    cmake -G"Visual Studio 16 2019" -T LLVM ..
 
 When using CMake with the Ninja generator, set the ``CMAKE_C_COMPILER`` and
 ``CMAKE_CXX_COMPILER`` variables to clang-cl:
 
   ::
 
     cmake -GNinja -DCMAKE_C_COMPILER="c:/Program Files (x86)/LLVM/bin/clang-cl.exe"
         -DCMAKE_CXX_COMPILER="c:/Program Files (x86)/LLVM/bin/clang-cl.exe" ..

lldb/docs/resources/build.rst

 and swig versions older than 4.0.0 which makes builds of LLDB using debug
 versions of python unusable. This primarily affects Windows, as debug builds of
 LLDB must use debug python as well.
 
 
 Windows
 *******
 
-* Visual Studio 2017.
+* Visual Studio 2019.
 * The latest Windows SDK.
 * The Active Template Library (ATL).
 * `GnuWin32 <http://gnuwin32.sourceforge.net/>`_ for CoreUtils and Make.
 * `Python 3 <https://www.python.org/downloads/windows/>`_.  Make sure to (1) get
   the x64 variant if that's what you're targetting and (2) install the debug
   library if you want to build a debug lldb. The standalone installer is the
   easiest way to get the debug library.
 * `Python Tools for Visual Studio

 #. Install Python 3 from the standalone installer and include the debug libraries
    in the install, making sure the Python install path is added to your PATH
    environment variable.
 #. Register the Debug Interface Access DLLs with the Registry from a privileged
    terminal.
 
 ::
 
-> regsvr32 "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\DIA SDK\bin\msdia140.dll"
-> regsvr32 "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\DIA SDK\bin\amd64\msdia140.dll"
+> regsvr32 "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\DIA SDK\bin\msdia140.dll"
+> regsvr32 "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\DIA SDK\bin\amd64\msdia140.dll"
 
 Any command prompt from which you build LLDB should have a valid Visual Studio
 environment setup. This means you should open an appropriate `Developer Command
 Prompt for VS <https://docs.microsoft.com/en-us/visualstudio/ide/reference/command-prompt-powershell?view=vs-2019>`_
 corresponding to the version you wish to use or run ``vcvarsall.bat`` or
 ``VsDevCmd.bat``.
 
 macOS

 cmake twice and generate the output into two different folders. One for
 compiling (the ninja folder), and one for editing, browsing and debugging.
 
 Follow the previous instructions in one directory, and generate a Visual Studio
 project in another directory.
 
 ::
 
-  $ cmake -G "Visual Studio 15 2017 Win64" -Thost=x64 <cmake variables> <path to root of llvm source tree>
+  $ cmake -G "Visual Studio 16 2019" -A x64 -T host=x64 <cmake variables> <path to root of llvm source tree>
 
 Then you can open the .sln file in Visual Studio, set lldb as the startup
 project, and use F5 to run it. You need only edit the project settings to set
 the executable and the working directory to point to binaries inside of the
 ninja tree.
 
 
 macOS

lldb/docs/resources/test.rst

 #. Set test/dotest.py as the startup file
 #. Make sure there is a Python Environment installed for your distribution. For example, if you installed Python to ``C:\Python35``, PTVS needs to know that this is the interpreter you want to use for running the test suite.
     #. Go to Tools -> Options -> Python Tools -> Environment Options
     #. Click Add Environment, and enter Python 3.5 Debug for the name. Fill out the values correctly.
 #. Configure the project to use this debug interpreter.
     #. Right click the Project node in Solution Explorer.
     #. In the General tab, Make sure Python 3.5 Debug is the selected Interpreter.
     #. In Debug/Search Paths, enter the path to your ninja/lib/site-packages directory.
-    #. In Debug/Environment Variables, enter ``VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\``.
+    #. In Debug/Environment Variables, enter ``VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\``.
     #. If you want to enabled mixed mode debugging, check Enable native code debugging (this slows down debugging, so enable it only on an as-needed basis.)
 #. Set the command line for the test suite to run.
     #. Right click the project in solution explorer and choose the Debug tab.
     #. Enter the arguments to dotest.py.
     #. Example command options:
 
 ::
 

llvm/cmake/modules/CheckCompilerVersion.cmake

 # Check if the host compiler is new enough.
 # These versions are updated based on the following policy:
 #   llvm.org/docs/DeveloperPolicy.html#toolchain
 
 include(CheckCXXSourceCompiles)
 
 set(GCC_MIN 5.1)
 set(GCC_SOFT_ERROR 5.1)
 set(CLANG_MIN 3.5)
 set(CLANG_SOFT_ERROR 3.5)
 set(APPLECLANG_MIN 6.0)
 set(APPLECLANG_SOFT_ERROR 6.0)
 
 # https://en.wikipedia.org/wiki/Microsoft_Visual_C#Internal_version_numbering
-# _MSC_VER == 1914 MSVC++ 14.14 (Visual Studio 2017 version 15.4)
-set(MSVC_MIN 19.14)
-set(MSVC_SOFT_ERROR 19.14)
+# _MSC_VER == 1920 MSVC++ 14.20 Visual Studio 2019 Version 16.0
+# _MSC_VER == 1927 MSVC++ 14.27 Visual Studio 2019 Version 16.7
+set(MSVC_MIN 19.20)
+set(MSVC_SOFT_ERROR 19.27)
 
 # Map the above GCC versions to dates: https://gcc.gnu.org/develop.html#timeline
 set(GCC_MIN_DATE 20150422)
 set(GCC_SOFT_ERROR_DATE 20150422)
 
 
 if(DEFINED LLVM_COMPILER_CHECKED)
   return()

llvm/docs/CMake.rst

**LLVM_ENABLE_FFI**:BOOL
   FFI_LIBRARY_DIR to the directories where ffi.h and libffi.so can be found,
   respectively. Defaults to OFF.
 
 **LLVM_ENABLE_IDE**:BOOL
   Tell the build system that an IDE is being used. This in turn disables the
   creation of certain convenience build system targets, such as the various
   ``install-*`` and ``check-*`` targets, since IDEs don't always deal well with
   a large number of targets. This is usually autodetected, but it can be
-  configured manually to explicitly control the generation of those targets. One
-  scenario where a manual override may be desirable is when using Visual Studio
-  2017's CMake integration, which would not be detected as an IDE otherwise.
+  configured manually to explicitly control the generation of those targets.
 
 **LLVM_ENABLE_LIBCXX**:BOOL
   If the host compiler and linker supports the stdlib flag, -stdlib=libc++ is
   passed to invocations of both so that the project is built using libc++
   instead of stdlibc++. Defaults to OFF.
 
 **LLVM_ENABLE_LIBPFM**:BOOL
   Enable building with libpfm to support hardware counter measurements in LLVM

llvm/docs/GettingStarted.rst

 
 LLVM is written using the subset of C++ documented in :doc:`coding
 standards<CodingStandards>`. To enforce this language version, we check the most
 popular host toolchains for specific minimum versions in our build systems:
 
 * Clang 3.5
 * Apple Clang 6.0
 * GCC 5.1
-* Visual Studio 2017
+* Visual Studio 2019
 
 Anything older than these toolchains *may* work, but will require forcing the
 build system with a special option and is not really a supported host platform.
 Also note that older versions of these compilers have often crashed or
 miscompiled LLVM.
 
 For less widely used host toolchains such as ICC or xlC, be aware that a very
 recent version may be required to support all of the C++ features used in LLVM.

 symptom is an error about cyclic dependencies.  We recommend upgrading to a
 newer version of Gold.
 
 Getting a Modern Host C++ Toolchain
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 This section mostly applies to Linux and older BSDs. On macOS, you should
 have a sufficiently modern Xcode, or you will likely need to upgrade until you
 do. Windows does not have a "system compiler", so you must install either Visual
-Studio 2017 or a recent version of mingw64. FreeBSD 10.0 and newer have a modern
-Clang as the system compiler.
+Studio 2019 (or later), or a recent version of mingw64. FreeBSD 10.0 and newer
+have a modern Clang as the system compiler.
 
 However, some Linux distributions and some other or older BSDs sometimes have
 extremely old versions of GCC. These steps attempt to help you upgrade you
 compiler even on such a system. However, if at all possible, we encourage you
 to use a recent version of a distribution with a modern system compiler that
 meets these requirements. Note that it is tempting to install a prior
 version of Clang and libc++ to be the host compiler, however libc++ was not
 well tested or set up to build on Linux until relatively recently. As

llvm/docs/GettingStartedVS.rst

 Requirements
 ============
 Before you begin to use the LLVM system, review the requirements given
 below.  This may save you some trouble by knowing ahead of time what hardware
 and software you will need.
 
 Hardware
 --------
-Any system that can adequately run Visual Studio 2017 is fine. The LLVM
+Any system that can adequately run Visual Studio 2019 is fine. The LLVM
 source tree including the git index consumes approximately 3GB.
 Object files, libraries and executables consume approximately 5GB in
 Release mode and much more in Debug mode. SSD drive and >16GB RAM are
 recommended.
 
 
 Software
 --------
-You will need `Visual Studio <https://visualstudio.microsoft.com/>`_ 2017 or
-higher, with the latest Update installed. Visual Studio Community Edition
+You will need `Visual Studio <https://visualstudio.microsoft.com/>`_ 2019 or
+later, with the latest Update installed. Visual Studio Community Edition
 suffices.
 
 You will also need the `CMake <http://www.cmake.org/>`_ build system since it
 generates the project files you will use to build with. CMake is bundled with
-Visual Studio 2019 so separate installation is not required.
+Visual Studio 2019 so separate installation is not required. If you do install
+CMake separately, Visual Studio 2022 will require CMake Version 3.21 or later.
 
 If you would like to run the LLVM tests you will need `Python
 <http://www.python.org/>`_. Version 3.6 and newer are known to work. You can
 install Python with Visual Studio 2019, from the Microsoft store or from
 the `Python web site <http://www.python.org/>`_. We recommend the latter since it
 allows you to to adjust installation options.
 
 You will need `Git for Windows <https://git-scm.com/>`_ with bash tools, too.

llvm/docs/ReleaseNotes.rst

* Using the legacy pass manager for the optimization pipeline is deprecated and
   will be removed after LLVM 14. In the meantime, only minimal effort will be
   made to maintain the legacy pass manager for the optimization pipeline.
 * Max allowed integer type was reduced from 2^24-1 bits to 2^23 bits.
 * Max allowed alignment was increased from 2^29 to 2^32.
 
 Changes to building LLVM
 ------------------------
 
-* ...
+* Building LLVM with Visual Studio now requires version 2019 or later.
 
 Changes to TableGen
 -------------------
 
 Changes to the AArch64 Backend
 ------------------------------
 
 * Added support for the Armv9-A, Armv9.1-A and Armv9.2-A architectures.

llvm/include/llvm/Support/Compiler.h

 /// * 1911: VS2017, version 15.3 & 15.4
 /// * 1912: VS2017, version 15.5
 /// * 1913: VS2017, version 15.6
 /// * 1914: VS2017, version 15.7
 /// * 1915: VS2017, version 15.8
 /// * 1916: VS2017, version 15.9
 /// * 1920: VS2019, version 16.0
 /// * 1921: VS2019, version 16.1
+/// * 1922: VS2019, version 16.2
+/// * 1923: VS2019, version 16.3
+/// * 1924: VS2019, version 16.4
+/// * 1925: VS2019, version 16.5
+/// * 1926: VS2019, version 16.6
+/// * 1927: VS2019, version 16.7
+/// * 1928: VS2019, version 16.8 + 16.9
+/// * 1929: VS2019, version 16.10 + 16.11
+/// * 1930: VS2022, version 17.0
 #ifdef _MSC_VER
 #define LLVM_MSC_PREREQ(version) (_MSC_VER >= (version))
 
-// We require at least MSVC 2017.
-#if !LLVM_MSC_PREREQ(1910)
-#error LLVM requires at least MSVC 2017.
+// We require at least VS 2019.
+#if !LLVM_MSC_PREREQ(1920)
+#error LLVM requires at least VS 2019.
 #endif
 
 #else
 #define LLVM_MSC_PREREQ(version) 0
 #endif
 
 /// Does the compiler support ref-qualifiers for *this?
 ///
 /// Sadly, this is separate from just rvalue reference support because GCC
 /// and MSVC implemented this later than everything else. This appears to be
 /// corrected in MSVC 2019 but not MSVC 2017.
-#if __has_feature(cxx_rvalue_references) || defined(__GNUC__) ||               \
-    LLVM_MSC_PREREQ(1920)
+/// FIXME: Remove LLVM_HAS_RVALUE_REFERENCE_THIS macro
 #define LLVM_HAS_RVALUE_REFERENCE_THIS 1
-#else
-#define LLVM_HAS_RVALUE_REFERENCE_THIS 0
-#endif
 
 /// Expands to '&' if ref-qualifiers for *this are supported.
 ///
 /// This can be used to provide lvalue/rvalue overrides of member functions.
 /// The rvalue override should be guarded by LLVM_HAS_RVALUE_REFERENCE_THIS
 #if LLVM_HAS_RVALUE_REFERENCE_THIS
 #define LLVM_LVALUE_FUNCTION &
 #else