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–16

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.

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)

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

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.
 

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

include/llvm/Support/AlignOf.h

 ///
 /// This template is used to explicitly build up a collection of aligned
 /// character array types. We have to build these up using a macro and explicit
 /// specialization to cope with MSVC (at least till 2015) where only an
 /// integer literal can be used to specify an alignment constraint. Once built
 /// up here, we can then begin to indirect between these using normal C++
 /// template parameters.
 
-// MSVC requires special handling here.
-#ifndef _MSC_VER
-
 template<std::size_t Alignment, std::size_t Size>
 struct AlignedCharArray {
   alignas(Alignment) char buffer[Size];
 };
 
-#else // _MSC_VER
-
-/// Create a type with an aligned char buffer.
-template<std::size_t Alignment, std::size_t Size>
-struct AlignedCharArray;
-
-// We provide special variations of this template for the most common
-// alignments because __declspec(align(...)) doesn't actually work when it is
-// a member of a by-value function argument in MSVC, even if the alignment
-// request is something reasonably like 8-byte or 16-byte. Note that we can't
-// even include the declspec with the union that forces the alignment because
-// MSVC warns on the existence of the declspec despite the union member forcing
-// proper alignment.
-
-template<std::size_t Size>
-struct AlignedCharArray<1, Size> {
-  union {
-    char aligned;
-    char buffer[Size];
-  };
-};
-
-template<std::size_t Size>
-struct AlignedCharArray<2, Size> {
-  union {
-    short aligned;
-    char buffer[Size];
-  };
-};
-
-template<std::size_t Size>
-struct AlignedCharArray<4, Size> {
-  union {
-    int aligned;
-    char buffer[Size];
-  };
-};
-
-template<std::size_t Size>
-struct AlignedCharArray<8, Size> {
-  union {
-    double aligned;
-    char buffer[Size];
-  };
-};
-
-
-// The rest of these are provided with a __declspec(align(...)) and we simply
-// can't pass them by-value as function arguments on MSVC.
-
-#define LLVM_ALIGNEDCHARARRAY_TEMPLATE_ALIGNMENT(x) \
-  template<std::size_t Size> \
-  struct AlignedCharArray<x, Size> { \
-    __declspec(align(x)) char buffer[Size]; \
-  };
-
-LLVM_ALIGNEDCHARARRAY_TEMPLATE_ALIGNMENT(16)
-LLVM_ALIGNEDCHARARRAY_TEMPLATE_ALIGNMENT(32)
-LLVM_ALIGNEDCHARARRAY_TEMPLATE_ALIGNMENT(64)
-LLVM_ALIGNEDCHARARRAY_TEMPLATE_ALIGNMENT(128)
-
-#undef LLVM_ALIGNEDCHARARRAY_TEMPLATE_ALIGNMENT
-
-#endif // _MSC_VER
-
 namespace detail {
 template <typename T1,
           typename T2 = char, typename T3 = char, typename T4 = char,
           typename T5 = char, typename T6 = char, typename T7 = char,
           typename T8 = char, typename T9 = char, typename T10 = char>
 class AlignerImpl {
   T1 t1; T2 t2; T3 t3; T4 t4; T5 t5; T6 t6; T7 t7; T8 t8; T9 t9; T10 t10;