[LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk

[Aaron Ballman]

On Fri, Aug 22, 2014 at 12:42 PM, Chris Bieneman <beanz at apple.com> wrote:
> Starting a new thread to loop in cfe-dev and lldb-dev. For those not
> following along there has been a thread on llvm-dev about moving the minimum
> required Visual Studio version to 2013. The motivating reason is this will
> allow us to take advantage of a bunch of C++11 features that are not
> supported by MSVC 2012. According to MSDN
> (http://msdn.microsoft.com/en-us/library/hh567368.aspx) the list is:
>
> * Non-static data member initializers
> * Variadic templates
> * Initializer lists
> * Default template arguments for function templates
> * Expression SFINAE
> * Alias templates
> * Delegating constructors
> * Explicit conversion operators
> * Raw string literals
> * Defaulted and deleted functions
>
> From the discussion on LLVM-dev it is also believed that this may ease some
> development pain as people keep occasionally breaking LLVM trunk by using
> language features not available in MSVC.
>
> Original thread:
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075900.html
>
> Chandler’s proposal for moving forward is as follows:
> 1) Loop in cfe-dev and lldb-dev (Done!)
> 2) Wait until this email fully circulates in digests and LLVM Weekly so that
> everyone who has an objection can voice it
> 3) If there are no objections, Commit a change to the CMake build which
> errors on old MSVC versions
> 4) Revert and fix buildbots
> 5) Repeat 3 & 4 until no issues
> 6) Once the change is live for a week with no issues, update the
> documentation to reflect the minimum required MSVC version as 2013
>
> (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/076090.html)
>
> Feedback is greatly appreciated.

This thread has sort of stalled without a resolution. Alex, has your
team had the opportunity to weigh in on the subject yet?

We have run into a hard situation where MSVC 2012 is missing a feature
that we are currently relying on. We made some changes to ASTMatchers
to reduce the number of symbols generated in order to not require
/bigobj support (see http://reviews.llvm.org/D5485). This change
relies on function templates with default arguments, which MSVC does
not support (it generates a C4519 error in MSVC 2012), resulting in
red bots (http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/10721).

This is a considerably more interesting case (at least to me) than
hypothetical benefits -- if we retain MSVC 2012 support, we will also
require /bigobj support, have slower compile times for ASTMatcher
projects, and slower benchmarks for clang-tidy. This points to
concrete benefits to expediting switching away from MSVC 2012, which
is why I am pinging this thread again.

Thanks!

~Aaron