This is an archive of the discontinued LLVM Phabricator instance.

Raise the minimum Visual Studio version to VS2019
ClosedPublic

Authored by RKSimon on Nov 26 2021, 6:22 AM.

Details

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.

Diff Detail

Event Timeline

RKSimon created this revision.Nov 26 2021, 6:22 AM
RKSimon requested review of this revision.Nov 26 2021, 6:22 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptNov 26 2021, 6:22 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
jhenderson added inline comments.Nov 26 2021, 6:33 AM
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 added inline comments.Nov 26 2021, 9:00 AM
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 updated this revision to Diff 390082.Nov 26 2021, 9:07 AM

address comments

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 added inline comments.Nov 29 2021, 1:28 AM
llvm/include/llvm/Support/Compiler.h
103–106

I'll add a FIXME to this patch

RKSimon updated this revision to Diff 390283.Nov 29 2021, 1:37 AM

rebase and add FIXME

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.

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 added inline comments.Nov 29 2021, 7:55 AM
clang/docs/UsersManual.rst
3660

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

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 added inline comments.Nov 29 2021, 10:07 AM
clang/docs/UsersManual.rst
3660

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

compnerd added inline comments.Nov 29 2021, 11:13 AM
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 added a subscriber: mehdi_amini.

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.

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.

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.

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

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.

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?

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

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!

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)

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

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.

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.

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.

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.

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 updated this revision to Diff 390824.Nov 30 2021, 2:31 PM
RKSimon edited the summary of this revision. (Show Details)

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

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.

jrheath added a subscriber: jrheath.Dec 6 2021, 8:48 AM

ping?

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

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.

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.

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

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

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

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

rnk added a comment.Jan 7 2022, 4:10 PM

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

@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?

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.

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?

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 updated this revision to Diff 403574.Jan 27 2022, 3:25 AM

update lldb docs as well

Herald added a project: Restricted Project. · View Herald TranscriptJan 27 2022, 3:25 AM

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

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 updated this revision to Diff 403924.Jan 28 2022, 1:31 AM

update lldb cmake command

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 updated this revision to Diff 404076.Jan 28 2022, 10:09 AM

fix cut+paste typo

This revision is now accepted and ready to land.Jan 28 2022, 10:11 AM
This revision was landed with ongoing or failed builds.Jan 29 2022, 2:57 AM
This revision was automatically updated to reflect the committed changes.

@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?

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 <reviews@reviews.llvm.org>
Sent: Saturday, January 29, 2022 3:12:52 AM
To: llvm-dev@redking.me.uk <llvm-dev@redking.me.uk>; Reid Kleckner <rnk@google.com>; aaron.ballman@gmail.com <aaron.ballman@gmail.com>; zturner@roblox.com <zturner@roblox.com>; jh7370@my.bristol.ac.uk <jh7370@my.bristol.ac.uk>; llvm@meinersbur.de <llvm@meinersbur.de>; jan_svoboda@apple.com <jan_svoboda@apple.com>; greg_bedwell@sn.scee.net <greg_bedwell@sn.scee.net>; Stella Stamenova <stilis@microsoft.com>
Cc: jonas@devlieghere.com <jonas@devlieghere.com>; lldb-commits@lists.llvm.org <lldb-commits@lists.llvm.org>; h.vetinari@gmx.com <h.vetinari@gmx.com>; vitalybuka@google.com <vitalybuka@google.com>; jrheng99@gmail.com <jrheng99@gmail.com>; reviews.llvm.org@jfbastien.com <reviews.llvm.org@jfbastien.com>; erich.keane@intel.com <erich.keane@intel.com>; joker.eph@gmail.com <joker.eph@gmail.com>; Saleem Abdulrasool <compnerd@compnerd.org>; russell.gallop@sony.com <russell.gallop@sony.com>; cfe-commits@lists.llvm.org <cfe-commits@lists.llvm.org>; mgorny@gentoo.org <mgorny@gentoo.org>; martin@martin.st <martin@martin.st>; llvm-commits@lists.llvm.org <llvm-commits@lists.llvm.org>; h.imai.833@nitech.jp <h.imai.833@nitech.jp>; bhuvanendra.kumarn@amd.com <bhuvanendra.kumarn@amd.com>; gandhi21299@gmail.com <gandhi21299@gmail.com>; yanliang.mu@intel.com <yanliang.mu@intel.com>; Liburd1994@outlook.com <Liburd1994@outlook.com>; serhiy.redko@gmail.com <serhiy.redko@gmail.com>; quic_sourabhs@quicinc.com <quic_sourabhs@quicinc.com>; dougpuob@gmail.com <dougpuob@gmail.com>; david.spickett@linaro.org <david.spickett@linaro.org>; mlekena@skidmore.edu <mlekena@skidmore.edu>; blitzrakete@gmail.com <blitzrakete@gmail.com>; shenhan@google.com <shenhan@google.com>; michael.hliao@gmail.com <michael.hliao@gmail.com>; bruce.mitchener@gmail.com <bruce.mitchener@gmail.com>; yuanfang.chen@sony.com <yuanfang.chen@sony.com>
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&amp;data=04%7C01%7Cstilis%40microsoft.com%7C1299827a2cee41cb745b08d9e3184ba9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637790515814400729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WccQ1%2B3T0IE2c%2BrjkWNmZIFZFsQaaGq6NIM8gpduOpY%3D&amp;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

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