Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 188263 Build 284420: arc lint + arc unit
Event Timeline
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.*.
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
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):
- VS 2013's support lifecycle, documented at https://learn.microsoft.com/en-us/lifecycle/products/visual-studio-2013 , is ending soon: Apr 9, 2024.
- 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. |
Adding clang-vendors for awareness as this has the potential to impact folks vending clang.
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 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.
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.
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.
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.
I am not a user of the MSVC toolchain, so leaving this work to someone working on it is better:)
Or words to that effect. "19.0" isn't particularly descriptive.