This is an archive of the discontinued LLVM Phabricator instance.

[Driver] Ignore -fmsc-version= -fms-compatibility-version= values smaller than 19
AbandonedPublic

Authored by MaskRay on Sep 22 2022, 12:29 PM.

Details

Reviewers
aganea
hans
rnk
STL_MSFT
zequanwu
Group Reviewers
Restricted Project
Summary

It's perhaps time to drop support for MSVC<2015 (-std=c++11,
-fno-threadsafe-statics, and a lot of LangOptions::MSVC2015) compatibility
checking code).

Emit warnings for now.

Note: D92515/D103293 bumped MSVC required version for building llvm-project.

Event Timeline

MaskRay created this revision.Sep 22 2022, 12:29 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 22 2022, 12:29 PM
Herald added a subscriber: StephenFan. · View Herald Transcript
MaskRay requested review of this revision.Sep 22 2022, 12:29 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 22 2022, 12:29 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
rnk added a comment.Sep 22 2022, 1:20 PM

I don't see the MSVC build requirement as being related to the version of MSVC that clang-cl supports targeting. Those can be separate. That said, this might be the right time to sunset this compatibility logic.

If we do this, I'd like it to be a policy change. We should add a release note about dropping support for -fmsc-version=N for N<1900, and audit for other logic like this:
https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaDeclCXX.cpp#L6390

Bonus points for a warning when the user passes -fms-compatibility-version=18.*.

MaskRay updated this revision to Diff 462292.Sep 22 2022, 2:24 PM
MaskRay retitled this revision from [Driver] Drop MSVC<2015 tweaking to [Driver] Ignore -fmsc-version= -fms-compatibility-version= values smaller than 19.
MaskRay edited the summary of this revision. (Show Details)

.

There are a lot more hits for isCompatibleWithMSVC used with 2015 across the codebase. Do you want to handle them in a follow up? That's fine with me.

I would like to get a second opinion before doing this. +@aaron.ballman

hans added a comment.Sep 22 2022, 2:58 PM

I'm conflicted about this. I see where you're coming from, but I could imagine people using clang-cl with old VS versions e.g. to target old Windows. I agree we shouldn't go out of our way to support that, but do we think it's too much effort to keep the functionality we have (as defined by the lit tests) working?

A couple of notes/reminders that may help you make a decision here (I have no particular opinion as this doesn't impact how VS and microsoft/STL use Clang):

  1. VS 2013's support lifecycle, documented at https://learn.microsoft.com/en-us/lifecycle/products/visual-studio-2013 , is ending soon: Apr 9, 2024.
  1. VS 2013 was the last release before the current "v19" binary-compatible era (VS 2015/2017/2019/2022). Code compiled with VS 2013 can't link with any other version (the CRT became the UCRT and the STL changed) - I believe this makes it less likely that users are stuck on this version.

These kinds of compatibility changes generally should get a Discourse post for better visibility.

clang/docs/ReleaseNotes.rst
85

Or words to that effect. "19.0" isn't particularly descriptive.

aaron.ballman added a reviewer: Restricted Project.Sep 23 2022, 9:14 AM
aaron.ballman added a subscriber: andrew.w.kaylor.

Adding clang-vendors for awareness as this has the potential to impact folks vending clang.

These kinds of compatibility changes generally should get a Discourse post for better visibility.

Strong +1, this needs a community RFC to see if we have folks relying on this support. For example, Intel supports ICX as a drop-in replacement for cl, and I'm not certain what our MSVC compatibility requirements are (I'm trying to find out though; CC @andrew.w.kaylor
for awareness).

I'm conflicted about this. I see where you're coming from, but I could imagine people using clang-cl with old VS versions e.g. to target old Windows. I agree we shouldn't go out of our way to support that, but do we think it's too much effort to keep the functionality we have (as defined by the lit tests) working?

I'm also conflicted -- what's the pain point we're trying to solve with these changes? It doesn't seem like maintenance is an actual burden in practice.

If we do this, I'd like it to be a policy change. We should add a release note about dropping support for -fmsc-version=N for N<1900, and audit for other logic like this:
https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaDeclCXX.cpp#L6390

Do we have a policy written down anywhere for this? We have one for what versions of MSVC we'll support building LLVM with, but I don't think we have a policy for what versions of MSVC we'll support being compatible with. Given that we still have GCC compatibility hacks for GCC 4.2 (which we still report we emulate with the GNU version macros!) which came out in 2008, I'd like more motivation as for why we want to drop support for MSVC 2013 and a better understanding of how we decide when we no longer will support compatibility with an older compiler -- we should be able to communicate this to users so their expectations are set appropriately.

thieta added a subscriber: thieta.Sep 23 2022, 9:43 AM

I think we should define a policy for this. I doubt we have many users on these older versions but I think maybe we should give deprecation messages for at least one release before we drop it?

I am not a Windows driver user. This patch is entirely motivated by Windows discussions in D131465 and I want to make /std: default rule simple (say, clang 16 uses C++17 for every mode for Windows). If the -fno-threadsafe-statics compatibility change is considered too risky, perhaps I'll just change this patch to just do C++17.

hans added a comment.Sep 26 2022, 7:32 AM

I am not a Windows driver user. This patch is entirely motivated by Windows discussions in D131465 and I want to make /std: default rule simple (say, clang 16 uses C++17 for every mode for Windows). If the -fno-threadsafe-statics compatibility change is considered too risky, perhaps I'll just change this patch to just do C++17.

If the D131465 discussion decides to bump to c++17, I think we should just do that bump and not drop the other compatibility stuff.

MaskRay abandoned this revision.Sep 26 2022, 10:46 AM

I am not a user of the MSVC toolchain, so leaving this work to someone working on it is better:)