llvm dev - Aug 2014 - [LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk

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
<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
<http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/076090.html>)

Feedback is greatly appreciated.

Thanks,
-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/4e5da269/attachment.html>

On Fri, Aug 22, 2014 at 9:42 AM, 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.
>
Is there an existing policy on how supported compiler versions are
selected?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/b6a5e33f/attachment.html>

> On Aug 22, 2014, at 9:53 AM, Daniel Dilts <diltsman at gmail.com>
wrote:
> 
> On Fri, Aug 22, 2014 at 9:42 AM, Chris Bieneman <beanz at apple.com
<mailto: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.
> 
> Is there an existing policy on how supported compiler versions are
selected?
There was a discussion last year
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html
<http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html>) WRT
allowing LLVM to use C++11 features which established a precedent of supporting
compilers released back for two years, with a special caveat for Windows.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/6259bcbf/attachment.html>

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

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

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/llvm-dev/attachments/20140930/e31f9a2e/attachment.html>