[RFC] Raise the minimum Visual Studio version to VS2019

Project Infrastructure LLVM Dev List Archives
1

Now that VS2022 is on general release, LLVM is expected to build on VS2017, VS2019 and VS2022.

What are people's thoughts on raising the minimum supported version to latest VS2019 (_MSC_VER = 1927)? Customarily, we've only specifically supported the latest 2 versions of Visual Studio, with older versions being "allowed" (at your own risk) via the LLVM_FORCE_USE_OLD_TOOLCHAIN cmake flag.

I'm thinking we should either make the switch now, in plenty of time before the next release of LLVM, or we postpone it until shortly after the release branch is created (which I assume will be early 2022).

For the record, I haven't so far noticed any issues with supporting VS2017, VS2019 and VS2022 builds, so at this time I don't consider this very urgent, just a general maintenance task - although somebody out there may know of specific fixes in VS2019+ that could simplify LLVM handling for MSVC etc.

Cheers, Simon.

2

By our policy to support the last 2 major versions of VS, this is the
right thing to do. Removing support for old compiler versions lessens
the maintenance burden, e.g. when committing a change that happens to
run a bug/missing feature of VS2017.

If I am not mistaken, the value of the latest VS2019 is 1929, not 1927 [1].

Michael

[1] Predefined macros | Microsoft Docs

3

I'm in support of this proposal.

I hit an unexpected preprocessor behavior in VS2017, forcing me to revert a patch that removed some repetitive code (D95532). The flag that fixes the issue (`/experimental:preprocessor`) is only present in Visual Studio 2017 version 15.8 and later. Raising the minimum supported version to VS2019 would allow us to enable `/Zc:preprocessor` and re-land the patch.

Cheers,
Jan

4

I’m also personally in favour of this - a couple of months ago I ran into a bug with the VS2017 compiler that isn’t present in the VS2019 one, that was preventing me using std::enable_if in a way I’d have liked to. Being able to retire VS2017 support would simplify a few things for me.

James

5

Now that VS2022 is on general release, LLVM is expected to build on
VS2017, VS2019 and VS2022.

What are people's thoughts on raising the minimum supported version to
latest VS2019 (_MSC_VER = 1927)? Customarily, we've only specifically
supported the latest 2 versions of Visual Studio, with older versions
being "allowed" (at your own risk) via the LLVM_FORCE_USE_OLD_TOOLCHAIN
cmake flag.

I'm thinking we should either make the switch now, in plenty of time
before the next release of LLVM, or we postpone it until shortly after
the release branch is created (which I assume will be early 2022).

For the record, I haven't so far noticed any issues with supporting
VS2017, VS2019 and VS2022 builds, so at this time I don't consider this
very urgent, just a general maintenance task - although somebody out
there may know of specific fixes in VS2019+ that could simplify LLVM
handling for MSVC etc.

Personally, I am in favor of the switch. I think it has the chance to
make some minor code improvements such as removing workarounds like:

~Aaron

6

Thanks for the responses, it looks like making VS2019 the minimum supported version sooner rather than later will help a number of cases.

I’ll create a patch this weekend, for review next week when more people are back after the USA holiday.

Simon.

7

I’ve created a patch here:

8

So I’d like to ‘bump’ this conversation, since it was sent during Thanksgiving week I suspect many may have not seen this (And I’d very much like to avoid this getting reverted/complained about on those grounds).

That said, I believe the last time we discussed raising these versions (when JF and I pushed them to our current limits), the general direction was that we should minimize the amount of changes to our toolchains, which encouraged us at the time to move our requirements in lockstep. I personally would suggest we update GCC, Clang, and AppleClang at the same time.

9

So I’d like to ‘bump’ this conversation, since it was sent during Thanksgiving week I suspect many may have not seen this (And I’d very much like to avoid this getting reverted/complained about on those grounds).

That said, I believe the last time we discussed raising these versions (when JF and I pushed them to our current limits), the general direction was that we should minimize the amount of changes to our toolchains,

which encouraged us at the time to move our requirements in lockstep. I personally would suggest we update GCC, Clang, and AppleClang at the same time.

Can you expand on why? It really isn’t obvious to me. I believe in particular that MSVC was singled out because Windows does not work like “Linux distribution” and the pattern of users made it reasonable to expect to support the last two major versions.

Thanks,

10

So I’d like to ‘bump’ this conversation, since it was sent during Thanksgiving week I suspect many may have not seen this (And I’d very much like to avoid this getting reverted/complained about on those grounds).

That said, I believe the last time we discussed raising these versions (when JF and I pushed them to our current limits), the general direction was that we should minimize the amount of changes to our toolchains,

which encouraged us at the time to move our requirements in lockstep. I personally would suggest we update GCC, Clang, and AppleClang at the same time.

Can you expand on why? It really isn't obvious to me. I believe in particular that MSVC was singled out because Windows does not work like "Linux distribution" and the pattern of users made it reasonable to expect to support the last two major versions.

As I recall, we did single out MSVC specifically because there is no
LTS release concept for developers using that toolchain to be tied to,
unlike GCC, etc. The best approach we could come up with at the time
was "last two releases" because releases were happening at a slow
enough cadence for that to make sense. With the new release cycles for
MSVC, I don't think "last two releases" makes sense any longer.

That said, I'm also happy to see our GCC and Clang requirements
updated if that's reasonable to do so. GCC 5.1 was released April 2015
and Clang 3.5 was released Sept 2014, so these are not particularly
new toolchains. Frankly, my biggest driver is the ability to
eventually use C++17 in the code base. I believe the most responsible
way for us to do that is to upgrade compilers before we switch default
language modes so that we're not changing too much at once, which
makes regressions easier to track down and report. However, getting a
newer toolchain by itself is a good end result (we know we're doing
the upgrades at some point and smaller version deltas are often less
risky than larger version deltas).

~Aaron

11

That said, I’m also happy to see our GCC and Clang requirements
updated if that’s reasonable to do so. GCC 5.1 was released April 2015
and Clang 3.5 was released Sept 2014, so these are not particularly
new toolchains.

In the past, we have used availability in stable OSs as merit for upgrading the minimum.

On *nix distros, release support usually ~2 years, give or take.

These are all old releases:
(Source: https://pkgs.org/)

Ubuntu 18.04 has clang 6 and gcc 7.3
Ubuntu 20.04 has clang 10 and gcc 9.3
Fedora 33 has clang 11 and gcc 9.2
Debian Stretch has clang 7 and gcc 6.1
Centos 8 has clang 12 gcc 8.5
FreeBSD 12 has clang 11 gcc 6.5 (and 9.3)
OpenSUSE 15 has clang 9 and gcc 7.5

Minimum clang and gcc is around 6.x.

I’m not sure on Mac, but I assume they have a more aggressive goals for the system compiler than many of the Linux/BSD distros and probably have a newer clang than most of them (at the same age).

With clang being the system compiler for Mac and BSD, getting a newer gcc would be just a matter of looking at ports-equivalent.

On Windows, neither clang nor gcc are the system compiler, so not hard to get the latest version.

Frankly, my biggest driver is the ability to
eventually use C++17 in the code base. I believe the most responsible
way for us to do that is to upgrade compilers before we switch default
language modes so that we’re not changing too much at once, which
makes regressions easier to track down and report. However, getting a
newer toolchain by itself is a good end result (we know we’re doing
the upgrades at some point and smaller version deltas are often less
risky than larger version deltas).

+1 to all that.

Much of C++17 support is in GCC 6, but GCC 7 is a safer bet.
(Source: https://gcc.gnu.org/projects/cxx-status.html#cxx17)

Clang 5, 6 and 7 have varying degrees of C++17 support, with clang 8 being the last that added something substantial.
(Source: https://clang.llvm.org/cxx_status.html#cxx17)

With that in mind, and the fact that *nix distros have ways to get a newer compiler if needed (ports/PPA), I’d say:

Clang/GCC 6 is a safe minimum, but Clang/GCC 7 is a better move, if we don’t want to change it too soon.

cheers,
–renato

12

Can you expand on why? It really isn’t obvious to me. I believe in particular that MSVC was singled out because Windows does not work like “Linux distribution” and the pattern of users made it reasonable to expect to support the last two major versions.

Updating toolchains is really painful for both on my downstream’s testing AND infrastructure (and for others). For those of us living off of trunk, every time we bump these numbers our infrastructure teams need to put together an ‘emergency’ response to get us working again. Doing this in lockstep means it saves us a significant amount of time and effort, vs doing it as 2 separate patches.

13

Can you expand on why? It really isn’t obvious to me. I believe in particular that MSVC was singled out because Windows does not work like “Linux distribution” and the pattern of users made it reasonable to expect to support the last two major versions.

Updating toolchains is really painful for both on my downstream’s testing AND infrastructure (and for others). For those of us living off of trunk, every time we bump these numbers our infrastructure teams need to put together an ‘emergency’ response to get us working again. Doing this in lockstep means it saves us a significant amount of time and effort, vs doing it as 2 separate patches.

I agree that updating toolchains is painful, and that can be a reason to not upgrade too often. It is actually a counter argument to “upgrade by small steps”: better to upgrade less frequently and to minimum versions of compilers well identified in long-term supported distributions (somehow like Renator described).

Now I don’t quite understand the connection to “doing it in lockstep”? In particular MSVC and *nix infra are fairly different in general (I maintain Docker images for our linux testing, it really isn’t clear what is the cross-cutting impact to Windows here).

14

Now I don’t quite understand the connection to “doing it in lockstep”? In particular MSVC and *nix infra are fairly different in general (I maintain Docker images for our linux testing, it really isn’t clear what is the cross-cutting impact to Windows here).

While the actual ‘update this compiler’ on a machine is different between the two, the process to get to the point where we can do that has a lot of overlap. In addition, the ‘emergency response’ component to updating this for our infrastructure is sizable, so doing it 1x reduces the effort by nearly half (vs in 2 separate commits).