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

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

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;