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

+1 for 2013. The feature set is worth it.

I expect that there will still be major incompatibilities around
initializer lists, so I would avoid them unless you have MSVC or are OK
with diagnosing the problem from a buildbot.


On Tue, Aug 19, 2014 at 11:12 AM, Renato Golin <renato.golin at
linaro.org>
wrote:
> I just broke a build by committing initializer list and a few other
> C++11 stuff on the LoopVectorizer... :/
>
> cheers,
> --renato
>
> PS: The lld Windows bot is 2011, so that surely needs upgrading anyway...
>
> On 19 August 2014 00:48, David Blaikie <dblaikie at gmail.com> wrote:
> > For my money: variadic templates and some bug I hit when trying to use
> > forward_as_tuple.
> >
> > On Aug 18, 2014 4:02 PM, "Aaron Ballman" <aaron at
aaronballman.com> wrote:
> >>
> >> On Mon, Aug 18, 2014 at 6:54 PM, Chris Bieneman <beanz at
apple.com>
> wrote:
> >> > I’d like to propose raising the minimum required compiler for
the
> LLVM &
> >> > Clang trunks for Visual Studio to MSVC 2013.
> >> >
> >> > Doing 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
> >> >
> >> > Questions, comments, concerns, general feedback?
> >>
> >> We shifted the minimum MSVC version to 2012 in January of this
year,
> >> and have run into only a few issues where C++11 features exist in
MSVC
> >> 2013 but not MSVC 2012. So I'm wondering what problem this
solves in
> >> practice for our code base?
> >>
> >> Personally, I use MSVC 2013 instead of 2012. But I would hesitate
to
> >> switch to 2013 as the minimum supported version just yet. It's
been
> >> out for less than two years and until "14" drops, it is
the newest
> >> version of the compiler. When we made the switch, the goal was to
> >> support only the last two versions of MSVC, and I don't see
any strong
> >> evidence to support expediting that schedule. I think this is a
great
> >> plan for when "14" is officially released.
> >>
> >> ~Aaron
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140821/068b0935/attachment.html>

This thread hasn’t had too much traffic, but it sounds like many people are in
favor and there is no strong opposition. If I understand Aaron’s only objection
was based on preserving existing policy rather than a technical reason.

Anyone want to make the official call?

-Chris
> On Aug 21, 2014, at 4:16 PM, Reid Kleckner <rnk at google.com> wrote:
> 
> +1 for 2013. The feature set is worth it.
> 
> I expect that there will still be major incompatibilities around
initializer lists, so I would avoid them unless you have MSVC or are OK with
diagnosing the problem from a buildbot.
> 
> 
> On Tue, Aug 19, 2014 at 11:12 AM, Renato Golin <renato.golin at
linaro.org <mailto:renato.golin at linaro.org>> wrote:
> I just broke a build by committing initializer list and a few other
> C++11 stuff on the LoopVectorizer... :/
> 
> cheers,
> --renato
> 
> PS: The lld Windows bot is 2011, so that surely needs upgrading anyway...
> 
> On 19 August 2014 00:48, David Blaikie <dblaikie at gmail.com
<mailto:dblaikie at gmail.com>> wrote:
> > For my money: variadic templates and some bug I hit when trying to use
> > forward_as_tuple.
> >
> > On Aug 18, 2014 4:02 PM, "Aaron Ballman" <aaron at
aaronballman.com <mailto:aaron at aaronballman.com>> wrote:
> >>
> >> On Mon, Aug 18, 2014 at 6:54 PM, Chris Bieneman <beanz at
apple.com <mailto:beanz at apple.com>> wrote:
> >> > I’d like to propose raising the minimum required compiler for
the LLVM &
> >> > Clang trunks for Visual Studio to MSVC 2013.
> >> >
> >> > Doing 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
<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
> >> >
> >> > Questions, comments, concerns, general feedback?
> >>
> >> We shifted the minimum MSVC version to 2012 in January of this
year,
> >> and have run into only a few issues where C++11 features exist in
MSVC
> >> 2013 but not MSVC 2012. So I'm wondering what problem this
solves in
> >> practice for our code base?
> >>
> >> Personally, I use MSVC 2013 instead of 2012. But I would hesitate
to
> >> switch to 2013 as the minimum supported version just yet. It's
been
> >> out for less than two years and until "14" drops, it is
the newest
> >> version of the compiler. When we made the switch, the goal was to
> >> support only the last two versions of MSVC, and I don't see
any strong
> >> evidence to support expediting that schedule. I think this is a
great
> >> plan for when "14" is officially released.
> >>
> >> ~Aaron
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>      
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
> >
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140821/23f81c3a/attachment.html>

On Thu, Aug 21, 2014 at 4:35 PM, Chris Bieneman <beanz at apple.com>
wrote:
> This thread hasn’t had too much traffic, but it sounds like many people are
> in favor and there is no strong opposition. If I understand Aaron’s only
> objection was based on preserving existing policy rather than a technical
> reason.
>
> Anyone want to make the official call?
>
> -Chris
We came up with this policy because certain people in the community
wanted more time to test and move to new compilers. Those people
haven't had any input on this thread yet, so I would rather we not
jump ahead without being sure nobody is still depending on VS 2012. I
actually need to verify that we're not still depending on it
internally.

- Michael Spencer
>
> On Aug 21, 2014, at 4:16 PM, Reid Kleckner <rnk at google.com> wrote:
>
> +1 for 2013. The feature set is worth it.
>
> I expect that there will still be major incompatibilities around
initializer
> lists, so I would avoid them unless you have MSVC or are OK with diagnosing
> the problem from a buildbot.
>
>
> On Tue, Aug 19, 2014 at 11:12 AM, Renato Golin <renato.golin at
linaro.org>
> wrote:
>>
>> I just broke a build by committing initializer list and a few other
>> C++11 stuff on the LoopVectorizer... :/
>>
>> cheers,
>> --renato
>>
>> PS: The lld Windows bot is 2011, so that surely needs upgrading
anyway...
>>
>> On 19 August 2014 00:48, David Blaikie <dblaikie at gmail.com>
wrote:
>> > For my money: variadic templates and some bug I hit when trying to
use
>> > forward_as_tuple.
>> >
>> > On Aug 18, 2014 4:02 PM, "Aaron Ballman" <aaron at
aaronballman.com> wrote:
>> >>
>> >> On Mon, Aug 18, 2014 at 6:54 PM, Chris Bieneman <beanz at
apple.com>
>> >> wrote:
>> >> > I’d like to propose raising the minimum required compiler
for the
>> >> > LLVM &
>> >> > Clang trunks for Visual Studio to MSVC 2013.
>> >> >
>> >> > Doing 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
>> >> >
>> >> > Questions, comments, concerns, general feedback?
>> >>
>> >> We shifted the minimum MSVC version to 2012 in January of this
year,
>> >> and have run into only a few issues where C++11 features exist
in MSVC
>> >> 2013 but not MSVC 2012. So I'm wondering what problem this
solves in
>> >> practice for our code base?
>> >>
>> >> Personally, I use MSVC 2013 instead of 2012. But I would
hesitate to
>> >> switch to 2013 as the minimum supported version just yet.
It's been
>> >> out for less than two years and until "14" drops, it
is the newest
>> >> version of the compiler. When we made the switch, the goal was
to
>> >> support only the last two versions of MSVC, and I don't
see any strong
>> >> evidence to support expediting that schedule. I think this is
a great
>> >> plan for when "14" is officially released.
>> >>
>> >> ~Aaron
>> >>
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On Thu, Aug 21, 2014 at 7:35 PM, Chris Bieneman <beanz at apple.com>
wrote:
> This thread hasn’t had too much traffic, but it sounds like many people are
> in favor and there is no strong opposition. If I understand Aaron’s only
> objection was based on preserving existing policy rather than a technical
> reason.
>
> Anyone want to make the official call?
I am still opposed.

We told the community less than nine months ago (when we made the
C++11 switch) that we would support the last two versions of MSVC. Now
we're saying "only the latest version, because it has nice
things."
That would make sense if those nice things were something we couldn't
live without, or if there was a long delay for a new release of MSVC.
Neither of those things seem to be the case, so I'm not certain why we
would change our developer policy on three day's notice.

~Aaron