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

[Samuel Benzaquen]

On Tue, Sep 30, 2014 at 5:05 AM, Alexander Kornienko <alexfh at google.com>
wrote:

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

That CL was rolled back for 2 reasons, one of them being a missing C++11
feature from MSVC. I can easily workaround on that use case.

In general, I don't mind working around the missing features.
However, one works in more than one project. Each one might work with a
different subset of some version of the language. Less rules to remember
leads to less breakage.

_Sam


>
> 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/76da3c3e/attachment.html>