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

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Tue Aug 2 12:24:02 PDT 2016

> On Aug 2, 2016, at 10:24 AM, 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 <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."
> 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.
> 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?

I think in the end it comes down to a tradeoff between the added value of what features we gain by dropping an old compiler (MSVC, GCC, Clang…) compared to its user-based.

For example I believe last time we dropped an MSVC release we had a fairly large list of features: http://lists.llvm.org/pipermail/llvm-dev/2014-August/075869.html

What is the list of features for dropping VS2013?

(I don’t know about how widely VS2013 is still used in the community to evaluate the other side of the balance).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160802/21953b03/attachment.html>

More information about the llvm-dev mailing list