[RFC] Raising minimum required Visual Studio version to 2013 for trunk

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?

-Chris

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

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?

The motivation for me was when I started looking at cleaning up the cl::opts and really wished that I could use variadic templates. There was also a discussion on IRC about this last week, and it seemed like there was at least a little interest, which is why I bring it up.

-Chris

For my money: variadic templates and some bug I hit when trying to use forward_as_tuple.

I just broke a build by committing initializer list and a few other
C++11 stuff on the LoopVectorizer... :confused:

cheers,
--renato

PS: The lld Windows bot is 2011, so that surely needs upgrading anyway...

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

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

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

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

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.

This is the primary reason i started this thread, and nobody has yet said they are still depending on it.

-Chris

I don't mean to imply we should change this on three days notice, but I do think there seems to be quite a bit of interest and very little opposition. I think we should at least entertain moving forward sooner than the nebulous release date of MSVC 14 if nobody is tied to 2012.

-Chris

So:

1) When we had the discussion 9 months ago I specifically called out that
MSVC might be reasonable rev faster than other compilers due to the rapidly
improving feature set. I think that this thread is essentially exploring
the possibility of actually doing that.

2) I actually think the features listed are *very* valuable. If we can move
faster, I think we should. But there is an "if we can" in there.

3) I completely agree about the 3-days thing. This is a good start, and
none have really shouted in objection. That's a good sign, but I would wait
at least until next week so that we have an LLVM weekly post, and digests
etc go out so that you reach an even larger audience. You should also email
cfe-dev and lldb-dev because those projects are very impacted by this
change.

If next week, no one has raised an objection of the form "this would break
my usage of LLVM" or "I can't easily upgrade for N months", then I think we
should move forward. At that point I think you should commit something to
the CMake build which errors on old versions of MSVC *without* updating
documentation, policy or code. You'll probably have tto revert it and get
some bots updated. Once the build bot fallout is fixed, and that commit
stays in tree for roughly a week without shouting, I think we can update
the documentation.

-Chandler

That sounds like a reasonable plan to me, thanks!

~Aaron

I'll echo Michael here.

Nobody from our production compiler groups has weighed in yet. It will take time for them to learn about this thread and form a reply.

Despite my desires to use a Canadian-cross, our production compiler is built with MSVC. We surely wouldn't decide to switch to 2013 until we've done a complete testing cycle with it. That takes more than three days and involves doing compatibility testing of shipped games (e.g. playing all of them).

I haven't seen a reply from anybody who vends a production compiler built with MSVC weigh in. Are we the only ones that use MSVC and not a Canadian-cross?

That said, I need to ask the obvious "is it plugged in" questions:

* We absolutely have to ship a set of DLLs that run hosted in VS2012. Is there any sort of runtime incompatibility that would happen if we built with 2013, needed the 2013 CRT, but tried to run inside the VS2012 process? That would be a complete show stopper for us since we have a committed schedule for support of versions of VS that we host in.

* Has any size/performance testing been done to compare LLVM built with the two versions of MSVC? Perf regressions are bad, m'kay?

Alex

FWIW, it is this kind of problem that I worry about too -- hopefully folks
can try it out and report back?

Mixing Visual C++ 2012 and 2013 runtime DLLs should not a problem as long you don’t try to allocate a resource (FILE, memory,…) managed by one runtime DLL and access or release it in other runtime DLL that does not know about it. In general the runtime DLLs don’t coordinate resource management, unless the resource is actually managed by Windows behind the scenes. See here:

http://social.msdn.microsoft.com/Forums/vstudio/en-US/614c9181-33b7-4ffa-968d-a910bb68eb33/can-i-use-msvcrt100dll-with-visual-c-2013?forum=vcgeneral

Yaron

+1

--renato

That sounds fun, can we help? :slight_smile:

cheers,
--renato

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

I don't see it this way. We need a compiler on all platforms that can
conform to the same level of the standards. In most platforms, that's
GCC and Clang, on Windows, that's also MSVC.

The problem here is that Linux and Mac developers will test their code
on multiple combinations of { Linux, Mac } x { x86, x86_64, ARM,
AArch64 } and it'll work perfectly, until it reaches Windows and
breaks because the compiler can't handle it.

Solving this problem is not trivial, and relying on buildbots to tell
us what's wrong promotes a culture of trial and error that makes it
impossible to control the source at any level (ex reverting bugged
commits, or applying them back again).

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.

We're finding the hard way that it could have been a lot better if
MSVC 2012 were actually a modern compiler to begin with. We haven't
changed the minimum requirement anywhere else, and still, it's MSVC
that is breaking up. That's a clear sign that MSVC 2012 is *not*
compatible (feature-wise) with all our other minimum requirements.

IIRC, we "accepted" MSVC 2012 as the minimum requirement due to
pressure, not because we thought it was a good idea and we said it
would have to move faster than the others because of the sheer lack of
functionality. Now it's past 3.5 release and 3.6 will probably come
out in 2015, the sooner we start the move to a more modern MSVC, the
better it'll be when we actually release 3.6.

I think Chandler's idea to break it now and see how it goes, by
changing only the make files, is a good one. At least we'll make all
the problems visible, and will be able to tackle them one by one,
instead of waiting for some people to chime in, people that haven't
been involved yet?

I also believe that we need to answer Alex's questions before
anything. We can't just guess, as we're talking here of a possible
massive incompatibility problem on millions of software out there (and
the games we play!!), so that's a critical issue! :slight_smile:

But other than that, stakeholders should have been doing their
homework and trying 2013 ever since 9 months ago. It's most definitely
not 3 days ago.

cheers,
--renato

I’ll second this, for example Reanto, VC 2012 had lots of problems with your last patch but only one problem with VC 2013 which could be easily fixed (array initialization). VC C++ conformance is rapidly advancing and VC 2012 is not up to it.

Yaron