<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 30, 2014 at 5:05 AM, Alexander Kornienko <span dir="ltr"><<a href="mailto:alexfh@google.com" target="_blank" class="cremed">alexfh@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Sep 30, 2014 at 3:45 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank" class="cremed">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>On Fri, Aug 22, 2014 at 12:42 PM, Chris Bieneman <<a href="mailto:beanz@apple.com" target="_blank" class="cremed">beanz@apple.com</a>> wrote:<br>
> Starting a new thread to loop in cfe-dev and lldb-dev. For those not<br>
> following along there has been a thread on llvm-dev about moving the minimum<br>
> required Visual Studio version to 2013. The motivating reason is this will<br>
> allow us to take advantage of a bunch of C++11 features that are not<br>
> supported by MSVC 2012. According to MSDN<br>
> (<a href="http://msdn.microsoft.com/en-us/library/hh567368.aspx" target="_blank" class="cremed">http://msdn.microsoft.com/en-us/library/hh567368.aspx</a>) the list is:<br>
><br>
> * Non-static data member initializers<br>
> * Variadic templates<br>
> * Initializer lists<br>
> * Default template arguments for function templates<br>
> * Expression SFINAE<br>
> * Alias templates<br>
> * Delegating constructors<br>
> * Explicit conversion operators<br>
> * Raw string literals<br>
> * Defaulted and deleted functions<br>
><br>
> From the discussion on LLVM-dev it is also believed that this may ease some<br>
> development pain as people keep occasionally breaking LLVM trunk by using<br>
> language features not available in MSVC.<br>
><br>
> Original thread:<br>
> <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075900.html" target="_blank" class="cremed">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075900.html</a><br>
><br>
> Chandler’s proposal for moving forward is as follows:<br>
> 1) Loop in cfe-dev and lldb-dev (Done!)<br>
> 2) Wait until this email fully circulates in digests and LLVM Weekly so that<br>
> everyone who has an objection can voice it<br>
> 3) If there are no objections, Commit a change to the CMake build which<br>
> errors on old MSVC versions<br>
> 4) Revert and fix buildbots<br>
> 5) Repeat 3 & 4 until no issues<br>
> 6) Once the change is live for a week with no issues, update the<br>
> documentation to reflect the minimum required MSVC version as 2013<br>
><br>
> (<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/076090.html" target="_blank" class="cremed">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/076090.html</a>)<br>
><br>
> Feedback is greatly appreciated.<br>
<br>
</div></div>This thread has sort of stalled without a resolution. Alex, has your<br>
team had the opportunity to weigh in on the subject yet?<br>
<br>
We have run into a hard situation where MSVC 2012 is missing a feature<br>
that we are currently relying on. We made some changes to ASTMatchers<br>
to reduce the number of symbols generated in order to not require<br>
/bigobj support (see <a href="http://reviews.llvm.org/D5485" target="_blank" class="cremed">http://reviews.llvm.org/D5485</a>). This change<br>
relies on function templates with default arguments, which MSVC does<br>
not support (it generates a C4519 error in MSVC 2012), resulting in<br>
red bots (<a href="http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/10721" target="_blank" class="cremed">http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/10721</a>).<br>
<br>
This is a considerably more interesting case (at least to me) than<br>
hypothetical benefits -- if we retain MSVC 2012 support, we will also<br>
require /bigobj support, have slower compile times for ASTMatcher<br>
projects, and slower benchmarks for clang-tidy. This points to<br>
concrete benefits to expediting switching away from MSVC 2012, which<br>
is why I am pinging this thread again.<br></blockquote><div><br></div></div></div><div>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 <a href="http://reviews.llvm.org/rL218616" target="_blank" class="cremed">http://reviews.llvm.org/rL218616</a>.</div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>In general, I don't mind working around the missing features.</div><div>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.</div><div><br></div><div>_Sam</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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.</div><div> </div><div>-- Alex</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thanks!<br>
<span><font color="#888888"><br>
~Aaron<br>
</font></span><div><div><span style="color:rgb(34,34,34)"> </span><br></div></div></blockquote></div>
</div></div>
</blockquote></div><br></div></div>