llvm dev - Nov 2021 - [RFC] Raise the minimum Visual Studio version to VS2019

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]
https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170

Am Di., 23. Nov. 2021 um 05:56 Uhr schrieb Simon Pilgrim via llvm-dev
<llvm-dev at lists.llvm.org>:
>
> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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
> On Nov 23, 2021, at 5:47 PM, Michael Kruse via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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]
https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
> 
> Am Di., 23. Nov. 2021 um 05:56 Uhr schrieb Simon Pilgrim via llvm-dev
> <llvm-dev at lists.llvm.org>:
>> 
>> 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.
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev