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

I agree with everything you've said. Considering how much effort I
personally put in to ensuring people's code works with MSVC, I
understand the pains involved. :wink:

My opposition to this switch was the timing. When we researched "what
minimum can we live with for C++11" nine months ago, we determined
what versions would make sense, which included MSVC 2012, and told
people what the plan was. My concern was pulling the rug out from
under people who were relying on that determination without putting in
the proper research and giving them enough time to react.

All of the reasons for upgrading that have been pointed out are valid
and are opinions I share. At the same time, we've managed to get by
acceptably well for nine months. That is why I spoke up when the
original proposal came in asking to switch without putting forward a
concrete plan. Chandler has laid out a plan that I am really happy
with, and if we don't have any stakeholders who have a reliance on
MSVC 2012, I'm happy to up the minimum to MSVC 2013 because it is a
considerably better toolchain.

~Aaron

The fact that you spoke, and others echoed your views, is proof that
what you fear will not happen.

Chandler's plan is simply showing the failures before we switch, which
is exactly what we've done last time, what you're asking now, and what
we'll do next.

Progress is made by breaking small things, one at a time. :slight_smile:

cheers,
--renato

We're in violent agreement. :slight_smile:

~Aaron

Disclaimer: I work at Microsoft.

From your list: expression SFINAE is listed as “no”; and support for defaulted and deleted constructors is only partial in VS 2013 (see the recent blog post about VS 2014 CTP 3). Please report bugs you may find in VC 2013 if they aren’t fixed in the latest CTP. Thanks!

– Gaby

Hi,
Sorry for the delay in responding, we have been discussing this internally
and have not had time to do a proper investigation.

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?

I do not know the answer to either of Alex's questions, so I am a bit
concerned. Two weeks is not going to be enough to test the updates; two
months might be more realistic...

What is the impact on the static libraries (such as LLVMCore.lib or
ClangLex.lib)? Can libraries built with Visual Studio 2013 link with other
objects built with Visual Studio 2012 or earlier?

- Gao

Hi,
Sorry for the delay in responding, we have been discussing this internally
and have not had time to do a proper investigation.

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?

I do not know the answer to either of Alex's questions, so I am a bit
concerned. Two weeks is not going to be enough to test the updates; two
months might be more realistic...

What is the impact on the static libraries (such as LLVMCore.lib or
ClangLex.lib)? Can libraries built with Visual Studio 2013 link with other
objects built with Visual Studio 2012 or earlier?

- Gao

No, you cannot link C++ code compiled with one version of VS to C++
code compiled with a different version of VS. The C++ ABI and standard
library change between versions.

- Michael Spencer

Two months look very reasonable to me.

This is not a critical move, so we should do it one step at a time.
But it is an important move, so we should actually do it, preferably a
few months before 3.6 branches out.

cheers,
--renato

If it’s a DLL that only exposes a C api you can. That’s how, for example, your code can link against KERNEL32.DLL and others. If there is a C++ api though things change.

While that is correct, it does not hold for any of us because LLVM exposes a C++ API amongst it’s own components.

Alex