Retire VS2015 Support

[RKSimon]

Summary

As proposed here: https://lists.llvm.org/pipermail/llvm-dev/2019-June/133147.html

This patch raises the minimum supported version to build LLVM/Clang to Visual Studio 2017.

@chandlerc AFAICT this is independent of Google's internal problems with C++14 code which is just a gcc issue?

NOTE: As an example of some of the VS C++ hacks we can get rid of, I've included the alignas hack in the patch - but I'm NOT intending to include that in the actual commit, instead a follow up patch will be put up for review that more thoroughly remove the alignas/AlignedCharArray hacks throughout the codebase.

[RKSimon]

This time with the release notes change......

[aaron.ballman]

I think this patch should also update our user-facing documentation at the same time, such as https://clang.llvm.org/get_started.html, https://llvm.org/docs/GettingStarted.html, and https://llvm.org/docs/GettingStartedVS.html.

cmake/modules/CheckCompilerVersion.cmake

13 ↗

(On Diff #208376)

I'd appreciate a comment listing more information about what version this is (thanks, Microsoft, for your terrible versioning scheme for this product). I know we didn't have such a comment before, but Visual Studio 2017 is also known as 1910, 14.10, and 15.0 simultaneously, and 19.1 is one of the lesser-known designations.

[RKSimon]

Added wikipedia URL (trying) to explain the VS/VC versioning scheme....

Fixed LLVM GettingStarted docs - I can create a patch for the equivalent Clang doc if you want but the change is trivial.

[aaron.ballman]

LGTM, but you should wait for others to have a chance to discuss before committing. You can always do the Clang docs in a separate follow-up patch (I know the changes are trivial, I just wanted to make sure they were all taken care of).

[probinson]

So, the point of this is to be able to remove certain workarounds, rather than advance the language feature set, IIUC.
Note that not all workarounds can be removed if we claim our minimum is the very first release of VS2017; see my r361502, to work around something that all of the bots were happy with.
I'm "once burnt, twice shy" about this, because we're not verifying that our claimed minimum build compilers are actually usable.
What is the minimum version of VS2017 used by any bot? Perhaps we should assert that as the minimum, which then makes it my fault for having a too-old build compiler.

[RKSimon]

In D64326#1573909, @probinson wrote:

So, the point of this is to be able to remove certain workarounds, rather than advance the language feature set, IIUC.
Note that not all workarounds can be removed if we claim our minimum is the very first release of VS2017; see my r361502, to work around something that all of the bots were happy with.
I'm "once burnt, twice shy" about this, because we're not verifying that our claimed minimum build compilers are actually usable.
What is the minimum version of VS2017 used by any bot? Perhaps we should assert that as the minimum, which then makes it my fault for having a too-old build compiler.

Its a mixture of reasons including:

• It lets us clean out pre-VS2017 hacks (although I'm not surprised we have others that aren't going away)
• We typically only support the latest 2 versions of VS
• Avoid VS min versions getting tied to the gcc4/c++14 issues
• Its hard enough getting people to keep VS builds working as it is without trying to support versions going back too far.

Including _MSC_VER in the FIXME comment should help us strip out hacks as we go on.

I'm unclear how often the VS buildbots get updates outside of moving to a new release - we suggest applying the 'latest updates' of VS2017/19 but I don't anything enforces it, so your rL361502 fixes would need to stay.

[rnk]

All policy aside, let's drop VS 2015 so we can simplify our alignas usage. lgtm :)

---

In D64326#1573909, @probinson wrote:

So, the point of this is to be able to remove certain workarounds, rather than advance the language feature set, IIUC.
Note that not all workarounds can be removed if we claim our minimum is the very first release of VS2017; see my r361502, to work around something that all of the bots were happy with.
I'm "once burnt, twice shy" about this, because we're not verifying that our claimed minimum build compilers are actually usable.
What is the minimum version of VS2017 used by any bot? Perhaps we should assert that as the minimum, which then makes it my fault for having a too-old build compiler.

As someone who maintains one of these buildbots, I'm actually more interested in testing the latest update, since that's what new developers are more likely to be using, and it provides early detection of compatibility issues, such as https://llvm.org/PR42027. We could set up more testing in more configs, but there are certain aspects of buildbot that don't scale very well. Every new config generates a unique email per failure, bots take care and feeding, they ultimately cost money, etc. And the minimum version only approximates the set of bugs that may be present in any release between the oldest and the newest supported release.

I think it's enough to document which major versions are known to work, and that for best results, developers should use the latest update available of one of those releases. I think I just made a very long argument which can be summarized as, let's just maintain the status quo. Sorry. >_>

Actually, how about this: what if we linked from the documentation to some buildbot page that exposes the precise toolchain versions that are actively being used for testing? That way if a user has problems they can consult this list and rule out that environmental factor. You can infer some version info from some bot logs, but it's far from accessible.

llvm/trunk/cmake/modules/CheckCompilerVersion.cmake

 # Check if the host compiler is new enough.
 # These versions are updated based on the following policy:
 #   llvm.org/docs/DeveloperPolicy.html#toolchain
 
 include(CheckCXXSourceCompiles)
 
 set(GCC_MIN 4.8)
 set(GCC_SOFT_ERROR 5.1)
 set(CLANG_MIN 3.1)
 set(CLANG_SOFT_ERROR 3.5)
 set(APPLECLANG_MIN 3.1)
 set(APPLECLANG_SOFT_ERROR 6.0)
-set(MSVC_MIN 19.00.24213.1)
+
+# https://en.wikipedia.org/wiki/Microsoft_Visual_C#Internal_version_numbering
+# _MSC_VER == 1910 MSVC++ 14.1 (Visual Studio 2017 version 15.0)
+set(MSVC_MIN 19.1)
 set(MSVC_SOFT_ERROR 19.1)
 
 # Map the above GCC versions to dates: https://gcc.gnu.org/develop.html#timeline
 set(GCC_MIN_DATE 20130322)
 set(GCC_SOFT_ERROR_DATE 20150422)
 
 
 if(DEFINED LLVM_COMPILER_CHECKED)

llvm/trunk/docs/GettingStarted.rst

 
 The below versions currently soft-error as we transition to the new compiler
 versions listed above. The LLVM codebase is currently known to compile correctly
 with the following compilers, though this will change in the near future:
 
 * Clang 3.1
 * Apple Clang 3.1
 * GCC 4.8
-* Visual Studio 2015 (Update 3)
+* Visual Studio 2017
 
 Anything older than these toolchains *may* work, but will require forcing the
 build system with a special option and is not really a supported host platform.
 Also note that older versions of these compilers have often crashed or
 miscompiled LLVM.
 
 For less widely used host toolchains such as ICC or xlC, be aware that a very
 recent version may be required to support all of the C++ features used in LLVM.

 newer version of Gold.
 
 Getting a Modern Host C++ Toolchain
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 This section mostly applies to Linux and older BSDs. On macOS, you should
 have a sufficiently modern Xcode, or you will likely need to upgrade until you
 do. Windows does not have a "system compiler", so you must install either Visual
-Studio 2015 or a recent version of mingw64. FreeBSD 10.0 and newer have a modern
+Studio 2017 or a recent version of mingw64. FreeBSD 10.0 and newer have a modern
 Clang as the system compiler.
 
 However, some Linux distributions and some other or older BSDs sometimes have
 extremely old versions of GCC. These steps attempt to help you upgrade you
 compiler even on such a system. However, if at all possible, we encourage you
 to use a recent version of a distribution with a modern system compiler that
 meets these requirements. Note that it is tempting to install a prior
 version of Clang and libc++ to be the host compiler, however libc++ was not

llvm/trunk/docs/GettingStartedVS.rst

 Requirements
 ============
 Before you begin to use the LLVM system, review the requirements given
 below.  This may save you some trouble by knowing ahead of time what hardware
 and software you will need.
 
 Hardware
 --------
-Any system that can adequately run Visual Studio 2015 is fine. The LLVM
+Any system that can adequately run Visual Studio 2017 is fine. The LLVM
 source tree and object files, libraries and executables will consume
 approximately 3GB.
 
 Software
 --------
-You will need Visual Studio 2015 or higher, with the latest Update installed.
+You will need Visual Studio 2017 or higher, with the latest Update installed.
 
 You will also need the `CMake <http://www.cmake.org/>`_ build system since it
 generates the project files you will use to build with.
 
 If you would like to run the LLVM tests you will need `Python
 <http://www.python.org/>`_. Version 2.7 and newer are known to work. You will
 need `GnuWin32 <http://gnuwin32.sourceforge.net/>`_ tools, too.
 

llvm/trunk/docs/ReleaseNotes.rst

* The 2-field form of global variables ``@llvm.global_ctors`` and
   type is now mandatory. Specify `i8* null` to migrate from the obsoleted
   2-field form.
 
 * The ``byval`` attribute can now take a type parameter:
   ``byval(<ty>)``. If present it must be identical to the argument's
   pointee type. In the next release we intend to make this parameter
   mandatory in preparation for opaque pointer types.
 
+Changes to building LLVM
+------------------------
+
+* Building LLVM with Visual Studio now requires version 2017 or later.
+
+
 Changes to the ARM Backend
 --------------------------
 
  During this release ...
 
 
 Changes to the MIPS Target
 --------------------------