Upgrading to MSVC 2015

I think it’s been a little over a year since we bumped the minimum VS version to 2013. Are we planning to do the same for 2015? Update 2 is releasing soon, which is stable enough at least to ship Chromium.

Language wise, 2015 comes with a lot of new C++ features. The most interesting to people will probably be template aliases, C++11 constexpr, the thread_local keyword, and thread-safe function local statics (finally). A complete list of new C++ language support can be found here.

As far as the different LLVM subprojects are concerned, LLDB was always going to be the hardest get working with MSVC 2015 due to the fact that it embeds python as an extension module, but as the LLDB maintainer for Windows I tackled this early and I can say that it’s now done and we have completely transitioned to MSVC 2015 already in LLDB.

Since we are only supporting 2015 in LLDB moving forward, I have a slight preference to bumping this in LLVM sooner rather than later, but I’d like to hear other peoples’ thoughts on the matter as well.

I think it's been a little over a year since we bumped the minimum VS
version to 2013. Are we planning to do the same for 2015? Update 2 is
releasing soon, which is stable enough at least to ship Chromium.

In the past, we've supported the latest two major versions of Visual
Studio unless there is a strong use case for dropping the oldest
version. I don't believe any such use case has been brought up yet, so
I would imagine we will continue to support MSVC 2013 until the next
major release.

Language wise, 2015 comes with a lot of new C++ features. The most
interesting to people will probably be template aliases, C++11 constexpr,
the thread_local keyword, and thread-safe function local statics (finally).
A complete list of new C++ language support can be found here.

As far as the different LLVM subprojects are concerned, LLDB was always
going to be the hardest get working with MSVC 2015 due to the fact that it
embeds python as an extension module, but as the LLDB maintainer for Windows
I tackled this early and I can say that it's now done and we have completely
transitioned to MSVC 2015 already in LLDB.

Since we are only supporting 2015 in LLDB moving forward, I have a slight
preference to bumping this in LLVM sooner rather than later, but I'd like to
hear other peoples' thoughts on the matter as well.

Not everyone can upgrade to the latest version of the toolchain, even
if it has been released for a while. We did drop MSVC 2012 support
early, but MSVC 2015 was in RC or RTM stages by that point, and we had
some pretty big incentive to upgrade early (without function templates
supporting default arguments, the AST matcher DSL made for really slow
compiles of Clang itself, and resulted in a larger executable size
among other things, IIRC). I recall we had frequent build breaks from
MSVC 2012 not supporting basic C++11 language features or miscompiling
due to early support. I've not seen that be the case with MSVC 2013
except for the occasional issue with use of braced initializer lists.
Coupled with the fact that there's no future version of MSVC with an
imminent release, I would prefer to not bump unless it starts
significantly stifling our development efforts.

~Aaron

I can tell you that at least on the LLDB side, it was significantly stifling our development efforts. The requirement that embedding Python means you have to compile Python with the same compiler that you compile the program you’re embedding it in, and the fact that the only supported toolchain for Python 2.7 is VC 2008, and the fact that Python 2.7 doesn’t even compile with VC 2015, we were in a bit of a bind. The only practical solution for us was to support Python 3.5 (which is compiled with VC 2015 and solves the compiler / ABI compatibility problem through the UCRT).

Granted this was a bit of a special circumstance, but as it stands I am already calling VC 2013 “unsupported” for LLDB.

I can tell you that at least on the LLDB side, it was significantly stifling
our development efforts. The requirement that embedding Python means you
have to compile Python with the same compiler that you compile the program
you're embedding it in, and the fact that the only supported toolchain for
Python 2.7 is VC 2008, and the fact that Python 2.7 doesn't even compile
with VC 2015, we were in a bit of a bind. The only practical solution for
us was to support Python 3.5 (which is compiled with VC 2015 and solves the
compiler / ABI compatibility problem through the UCRT).

Granted this was a bit of a special circumstance, but as it stands I am
already calling VC 2013 "unsupported" for LLDB.

That's an excellent example of a reason to bump the compiler version
early for LLDB, but it's also not one shared by LLVM or Clang as we
don't have those constraints. (FWIW, I don't have a problem with just
LLDB dropping support for MSVC 2013, especially given the above.)

~Aaron

Total side note: Python 3.5 supports a vastly improved installer infrastructure, which lets you choose to install debug or release, will install symbols, and most awesomely supports a launcher that fixes the issues with 2.x & 3.x coexisting on one system.

For 2.x you just use the command “py -2 your_script.py”, and it just does the right thing. You can also explicitly call it with “-3” to get 3.x.

If you have an out-of-date version of 3.x, you should update, if only to get the launcher.

See more about the launcher: PEP 397 – Python launcher for Windows | peps.python.org

Btw, I can’t remember if this is explicit in the documentation: Does LLVM require the latest two updated versions of Visual Studio? (i.e. VS2013 update 5 & VS 2015 update 1)

I’ve seen people on the mailing list several times running an out of date version, which is nonsensical, and could cause strange problems.

Btw, I can't remember if this is explicit in the documentation: Does LLVM
require the latest two *updated* versions of Visual Studio? (i.e. VS2013
update 5 & VS 2015 update 1)

I've seen people on the mailing list several times running an out of date
version, which is nonsensical, and could cause strange problems.

Yes, we require the latest updates to be installed, though we don't
currently document it (I'll go fix that).

~Aaron

> I think it's been a little over a year since we bumped the minimum VS
> version to 2013. Are we planning to do the same for 2015? Update 2 is
> releasing soon, which is stable enough at least to ship Chromium.

In the past, we've supported the latest two major versions of Visual
Studio unless there is a strong use case for dropping the oldest
version. I don't believe any such use case has been brought up yet, so
I would imagine we will continue to support MSVC 2013 until the next
major release.

> Language wise, 2015 comes with a lot of new C++ features. The most
> interesting to people will probably be template aliases, C++11 constexpr,
> the thread_local keyword, and thread-safe function local statics
(finally).
> A complete list of new C++ language support can be found here.
>
> As far as the different LLVM subprojects are concerned, LLDB was always
> going to be the hardest get working with MSVC 2015 due to the fact that
it
> embeds python as an extension module, but as the LLDB maintainer for
Windows
> I tackled this early and I can say that it's now done and we have
completely
> transitioned to MSVC 2015 already in LLDB.
>
> Since we are only supporting 2015 in LLDB moving forward, I have a slight
> preference to bumping this in LLVM sooner rather than later, but I'd
like to
> hear other peoples' thoughts on the matter as well.

Not everyone can upgrade to the latest version of the toolchain, even
if it has been released for a while. We did drop MSVC 2012 support
early, but MSVC 2015 was in RC or RTM stages by that point, and we had
some pretty big incentive to upgrade early (without function templates
supporting default arguments, the AST matcher DSL made for really slow
compiles of Clang itself, and resulted in a larger executable size
among other things, IIRC). I recall we had frequent build breaks from
MSVC 2012 not supporting basic C++11 language features or miscompiling
due to early support. I've not seen that be the case with MSVC 2013
except for the occasional issue with use of braced initializer lists.

The most common one I see here ^ is MSVC 2013's inability to generate
implicit definitions of move special members. Comes up pretty regularly.

I know you mentioned that one of the reasons we upgraded to 2013 was because 2015 was in RC or RTM. Ironically, the day after I posted this MS announced Visual Studio 15 preview (which is confusingly the version after Visual Studio 2015). In any case, it’s not an RC, and it’s certainly not an RTM, but it is on the horizon. So hopefully we can revisit this question when 15 is in RC / RTM

Not everyone can upgrade to the latest version of the toolchain, even
if it has been released for a while. We did drop MSVC 2012 support
early, but MSVC 2015 was in RC or RTM stages by that point, and we had
some pretty big incentive to upgrade early (without function templates
supporting default arguments, the AST matcher DSL made for really slow
compiles of Clang itself, and resulted in a larger executable size
among other things, IIRC).

I know you mentioned that one of the reasons we upgraded to 2013 was because
2015 was in RC or RTM. Ironically, the day after I posted this MS announced
Visual Studio 15 preview (which is confusingly the version *after* Visual
Studio 2015).

Hah, that is confusing!

In any case, it's not an RC, and it's certainly not an RTM,
but it is on the horizon. So hopefully we can revisit this question when 15
is in RC / RTM

I think that's a great time to revisit the question (transitioning
sometimes takes a bit of time since we want to ask people with out of
tree needs if they're ready before dropping support for major
releases).

~Aaron

https://www.visualstudio.com/en-us/news/vs2015-vs.aspx

Is it time?

Probably not. It’s very confusing because they are transitioning to a new versioning scheme. The current version if Visual Studio 2015. The next version is Visual Studio 15. The link you posted was for the RTM of 2015, just over a year ago. But 15 is still in Preview. When 15 goes to RTM, then we can revisit the question of making 2015 the minimum required version.

There are certainly enough people making commits that work with VS2015 but not VS2013 that the “would it be useful” question is pretty well answered. I’ve already brought up the idea on my team, as it’s obviously coming and we need time to coordinate with internal consumers of the toolchain.

–paulr

There are certainly enough people making commits that work with VS2015 but
not VS2013 that the "would it be useful" question is pretty well answered.
I've already brought up the idea on my team, as it's obviously coming and
we need time to coordinate with internal consumers of the toolchain.

Also, we have an increasing number of parts of the codebase that are
working around VS2013's inability to generate move constructors.
This is all over the new PM code and the passes ported to the new PM.
It has caused me personally hours of lost time and generally penalizes good
coding practices (exporting lifetime management to RAII is only so
convenient if you can't have a move-only type like a unique_ptr without
manually writing out move constructor/assign; and the diagnostics when this
VS2013 deficiency raises its head are.... confusing).

-- Sean Silva

FWIW, no objections from me, after all I proposed this 3 months ago :slight_smile:

Probably Aaron Ballman should comment though since the primary objection last time was his.

There are not that many people making commits to working around MSVC
2013 as I think are claimed (there are certainly a lot of commits for
working around MSVC in general, however). A quick search through the
code base shows there are 8 instances where we've worked around MSVC
2013 issues (there may be more that someone worked around in an ad hoc
manner and did not mark). We definitely had *a lot* more when we
dropped MSVC 2012 early. The primary issues people are working around
are constexpr support, which is important but certainly not critical,
and still some occasional issues with move constructors not being
synthesized as expected, which is also pretty simple to work around
(and is usually an optimization loss more than a functionality loss).

As MSVC 15 starts getting closer to the RTM stages, I think we should
definitely consider the switch more strongly, but with it still in
Preview mode, I think it's premature to drop support for MSVC 2013 at
this time.

~Aaron

From: aaron.ballman@gmail.com [mailto:aaron.ballman@gmail.com] On Behalf
Of Aaron Ballman
Sent: Friday, July 29, 2016 2:19 PM
To: Zachary Turner
Cc: Sean Silva; Robinson, Paul; Piotr Padlewski; llvm-dev@lists.llvm.org
Subject: Re: [llvm-dev] Upgrading to MSVC 2015

There are not that many people making commits to working around MSVC
2013 as I think are claimed

CGOpenMPRuntime.cpp had 4 patches this week trying to make VS2013 happy.
I can tell they were because of VS2013 because the public PS4 bot has
VS2015 and it didn't seem to have the same problems.
Maybe it was just bad luck that we put up an internal VS2013 bot when it
happened, but it has been an incredible time-sink for me this week.

Note I do not want to advance the timetable, I just want to make sure
that the actual problems aren't dismissed too readily.
--paulr

From: aaron.ballman@gmail.com [mailto:aaron.ballman@gmail.com] On Behalf
Of Aaron Ballman
Sent: Friday, July 29, 2016 2:19 PM
To: Zachary Turner
Cc: Sean Silva; Robinson, Paul; Piotr Padlewski; llvm-dev@lists.llvm.org
Subject: Re: [llvm-dev] Upgrading to MSVC 2015

There are not that many people making commits to working around MSVC
2013 as I think are claimed

CGOpenMPRuntime.cpp had 4 patches this week trying to make VS2013 happy.
I can tell they were because of VS2013 because the public PS4 bot has
VS2015 and it didn't seem to have the same problems.

Hmmm, I don't see any mention in the code itself about changes to
appease MSVC 2013, so that's why it didn't come up in my searches. We
usually ask people working around buggy compilers to leave a FIXME in
there so we can remove compiler hacks (but obviously, we don't manage
to catch all of them), so if you run into anything like this again,
please try to put in a FIXME if it's appropriate.

Maybe it was just bad luck that we put up an internal VS2013 bot when it
happened, but it has been an incredible time-sink for me this week.

I'm sorry it's been a time sink for you!

Note I do not want to advance the timetable, I just want to make sure
that the actual problems aren't dismissed too readily.

Agreed -- if we have compiler problems that are causing a lot of pain,
I think it's a good idea to discuss bumping the time table. However,
we have problems with *every* compiler from time to time. For
comparison, when we dropped MSVC 2012 early we had frequent
(weekly-ish?) issues that we would run up against that 2013 had
already fixed, the workarounds were cumbersome, and 2013 had a looming
release date. We do run into issues with 2013 (I helped someone work
around one yesterday, in fact), so it's good for us to keep track of
those situations to help make informed decisions, but whether we're at
the point of deviating from our compiler support policy or not is less
clear to me.

~Aaron

From: aaron.ballman@gmail.com [mailto:aaron.ballman@gmail.com] On Behalf
Of Aaron Ballman
Sent: Saturday, July 30, 2016 12:41 PM
To: Robinson, Paul
Cc: Zachary Turner; Sean Silva; Piotr Padlewski; llvm-dev@lists.llvm.org
Subject: Re: [llvm-dev] Upgrading to MSVC 2015

>
>
>> From: aaron.ballman@gmail.com [mailto:aaron.ballman@gmail.com] On
Behalf
>> Of Aaron Ballman
>> Sent: Friday, July 29, 2016 2:19 PM
>> To: Zachary Turner
>> Cc: Sean Silva; Robinson, Paul; Piotr Padlewski; llvm-
dev@lists.llvm.org
>> Subject: Re: [llvm-dev] Upgrading to MSVC 2015
>>
>> There are not that many people making commits to working around MSVC
>> 2013 as I think are claimed
>
> CGOpenMPRuntime.cpp had 4 patches this week trying to make VS2013 happy.
> I can tell they were because of VS2013 because the public PS4 bot has
> VS2015 and it didn't seem to have the same problems.

Hmmm, I don't see any mention in the code itself about changes to
appease MSVC 2013, so that's why it didn't come up in my searches. We
usually ask people working around buggy compilers to leave a FIXME in
there so we can remove compiler hacks (but obviously, we don't manage
to catch all of them), so if you run into anything like this again,
please try to put in a FIXME if it's appropriate.

Ah, okay, was not aware of that policy. I'll try to keep that in mind
if it comes up again. It looks like other people with a more vested
interest in that module have also been working on it, so I'm not sure
exactly what its current state is; if my hacks are still there Monday
then I'll look at adding FIXME comments.
Thanks,
--paulr

There is also a chance that someone gonna extend clang-tidy check “modernize-use-default” to handle move constructors.
Then at least this problem, which I think is the most frequent, could be solved easily after moving to MSVC2015