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

Wed Dec 1 07:37:52 PST 2021

On Wed, Dec 1, 2021 at 6:10 AM Keane, Erich <erich.keane at intel.com> wrote:

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

>
>
> *From:* Mehdi AMINI <joker.eph at gmail.com>
> *Sent:* Tuesday, November 30, 2021 11:38 PM
> *To:* Keane, Erich <erich.keane at intel.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>; cfe-dev at lists.llvm.org
> *Subject:* Re: [cfe-dev] [llvm-dev] [RFC] Raise the minimum Visual Studio
> version to VS2019
>
>
>
>
>
>
>
> On Tue, Nov 30, 2021 at 10:44 AM Keane, Erich via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> 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,
>
>
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Simon
> Pilgrim via llvm-dev
> *Sent:* Friday, November 26, 2021 6:27 AM
> *To:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] [RFC] Raise the minimum Visual Studio version
> to VS2019
>
>
>
> I've created a patch here: https://reviews.llvm.org/D114639
>
> On 25/11/2021 13:51, Simon Pilgrim via llvm-dev wrote:
>
> 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
>
>
>
> _______________________________________________
>
> LLVM Developers mailing list
>
> llvm-dev at lists.llvm.org
>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211201/f837bc8d/attachment.html>