This is an archive of the discontinued LLVM Phabricator instance.

Retire VS2015 Support
ClosedPublic

Authored by RKSimon on Jul 8 2019, 5:45 AM.

Details

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.

Diff Detail

Repository
rL LLVM

Event Timeline

RKSimon created this revision.Jul 8 2019, 5:45 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 8 2019, 5:45 AM
RKSimon updated this revision to Diff 208376.Jul 8 2019, 5:47 AM

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

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 updated this revision to Diff 208391.Jul 8 2019, 6:37 AM

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 accepted this revision.Jul 8 2019, 6:43 AM

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

This revision is now accepted and ready to land.Jul 8 2019, 6:43 AM

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.

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 accepted this revision.Jul 8 2019, 11:34 AM

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


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.

This revision was automatically updated to reflect the committed changes.