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

[Alexander Kornienko]

On Tue, Sep 30, 2014 at 3:45 AM, Aaron Ballman <aaron at aaronballman.com>
wrote:

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

We regularly stumble upon C++11 features not supported by MSVC 2012 and
have to rollback patches after some buildbot breaks. Usually, it's easy to
work around, not sure about this case. It's probably better to ask the
author of http://reviews.llvm.org/rL218616.

So I'm personally both hands for switching the minimal supported MSVC
version to 2013. I understand though, that by requiring MSVC 2013, instead
of missing support of some language features we could get incomplete and
buggy support. But still looks like a better alternative to me.

-- Alex


> Thanks!
>
> ~Aaron
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140930/e31f9a2e/attachment.html>