[llvm-dev] Revisiting our informal policy to support two versions of MSVC

[Aaron Ballman via llvm-dev]

On Tue, Aug 2, 2016 at 1:24 PM, David Majnemer via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hello,
>
> Today we hit another VS 2013 breakage
> <http://lab.llvm.org:8011/builders/sanitizer-windows/builds/26666/steps/run%20tests/logs/stdio>
> which results us having to alter LLVM.
>
> While we have no documented policy of supporting two version of MSVC, we do
> have an informal agreement that we should support the last two versions.
>
> I suggest that we alter our informal policy to the following:
>
> "If a compiler version keeps getting in the way and a newer compiler is
> available, we should ask people to upgrade to that newer compiler."

I think that's reasonable, but I also think this is no different than
what we already do today, which is unfortunate. The lack of
predictability of when we drop support for MSVC is something I would
hope we can address. That's what the "last two versions" was hoping to
achieve, but hasn't in practice since we've never actually adhered to
that policy due to finding pain points to justify dropping early.
Since this proposal is basically preserving the status quo, I don't
think predictability needs to be solved in order to move forward with
the proposal of dropping support for 2013.

To me, the goal of having some degree of predictability with compiler
versions is for people with out-of-tree projects to have a chance of
knowing when support for a compiler may be dropped and plan
accordingly. This isn't traditionally a problem with GCC (e.g.)
because the stability of features and functionality is usually a bit
higher than with MSVC, where major upgrades can be challenging and
labor-intensive for some projects. Maybe we can bring back the notion
of  "last two versions" sometime in the future if MSVC functionality
stabilizes a bit more.

> If we can support ten versions of MSVC with little burden, I don't see a
> reason why we shouldn't.
>
> But if we find ourselves in a situation where asking folks to upgrade to a
> compiler which has been widely deployed soothes development for the greater
> LLVM community, we should consider dropping support for the older versions
> of that compiler.

Totally agreed.

> In this case, dropping VS2013 allows us to use more C++11 features with
> confidence.  Notably, move constructors will be synthesized instead of
> having to be manually written (and kept in sync with data members getting
> added).
>
> What do you all think?  Are folks still stuck on VS2013?

Assuming that we don't have any major barriers to dropping MSVC 2013,
I am okay with it. Additional request: can we also informally require
the latest Update to be installed for whatever versions of MSVC we
support (if we don't already)? I don't see a whole lot of value to
keeping support for Update 1 & 2 when Update 3 is out.

~Aaron

>
> Thanks,
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>