[lldb-dev] [cfe-dev] [LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk

[Robinson, Paul]

> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On
> Behalf Of Aaron Ballman
> Sent: Monday, September 29, 2014 4:45 PM
> To: Chris Bieneman
> Cc: lldb-dev at cs.uiuc.edu; cfe-dev Developers; LLVM Developers Mailing List
> Subject: Re: [cfe-dev] [LLVMdev] [RFC] Raising LLVM minimum required MSVC
> version to 2013 for trunk
> 
> 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?

I'm expecting to have our internal builds switched over later this
week.  Our investigations have shown no problems.

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

I have a sad bot failing to build in Debug mode, glad to know there's
a fix in the works.

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

I guess I'm a little surprised that /bigobj is such a compile-time hit,
but haven't tried any benchmarking. Anyway, whatever works best for you.
--paulr

> 
> Thanks!
> 
> ~Aaron
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev