James Henderson via llvm-dev
2021-Nov-25 12:57 UTC
[llvm-dev] [RFC] Raise the minimum Visual Studio version to VS2019
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 On Thu, 25 Nov 2021 at 12:30, Jan Svoboda via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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 > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211125/41e6ee0b/attachment-0001.html>
Simon Pilgrim via llvm-dev
2021-Nov-25 13:51 UTC
[llvm-dev] [RFC] Raise the minimum Visual Studio version to VS2019
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. On 25/11/2021 12:57, James Henderson via llvm-dev wrote:> 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 > > On Thu, 25 Nov 2021 at 12:30, Jan Svoboda via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 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 > > _______________________________________________ > 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211125/61d3b697/attachment.html>