[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D131465#3809413 <https://reviews.llvm.org/D131465#3809413>, @hans wrote:

> In D131465#3808381 <https://reviews.llvm.org/D131465#3808381>, @aaron.ballman wrote:
>
>> In D131465#3806709 <https://reviews.llvm.org/D131465#3806709>, @MaskRay wrote:
>>
>>> In D131465#3804893 <https://reviews.llvm.org/D131465#3804893>, @glandium wrote:
>>>
>>>> This didn't change the default for msvc targets, was that expected?
>>>
>>> I think it is expected (but I did not know when I made the change)
>>>
>>> https://learn.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-170 says the default is `/std:c++14`.
>>> If I use `/Zc:__cplusplus` on godbolt.org, I get `__cplusplus => 201402`. I think clang-cl likely wants to follow MSVC.
>>> The relevant code is around https://github.com/llvm/llvm-project/blob/669e508772e5e00db6285d699ee82a428dc00f32/clang/lib/Driver/ToolChains/Clang.cpp#L6628
>>
>> I don't recall us sticking with the MSVC defaults the last time we bumped default language versions, but I've not gone back through email to look yet. Regardless, I don't think it's ergonomic for Clang to have a different default language standard for Windows targets -- that means when I run tests, they're all run in C++14 mode but when my coworker runs them, they're all C++17; we will assuredly run into "why does this test behave differently for you than me?" problems from diverging. Not everyone using clang is using clang-cl, so I think clang should default to the same language version for Windows as Linux. I think it's reasonable for clang-cl specifically to default to what MSVC does though. (CC @hans @majnemer @rnk to see if they recall details or have opinions.)
>
> I also don't recall the details here, but digging through the history:
>
> The last bump was D40948 <https://reviews.llvm.org/D40948>.
> Like this one, it also did not do anything special for Windows.
> But at that point we already had https://github.com/llvm/llvm-project/commit/093012bf6e6d450b0396a1803ff5197a8037c893 which used c++14 for recent windows-msvc targets.
>
> As maskray checked, the msvc default doesn't seem to have changed.
>
>> I don't think it's ergonomic for Clang to have a different default language standard for Windows targets -- that means when I run tests, they're all run in C++14 mode but when my coworker runs them, they're all C++17
>
> Clang already has often had different defaults for different targets, such as PS4. Having a different one for windows-msvc, that matches msvc's default, seems reasonable to me.

I guess I view less common targets like PS4 differently than I do common targets like x64 Windows. The number of people likely to notice that PS4 is different from the other targets seems far smaller than the number of people noticing the same for Windows. But I've got no data to back that up, either.

> If we changed our default for windows, the "why does this test behave differently for you than me?" problem would still be there, except between clang and msvc colleagues.

If we're all using `clang` for the command, we'd all get the same behavior, right? There's no expectation that `clang` and `cl` behave the same way, that's what `clang-cl` is for. I guess I don't see why we care about how MSVC behaves unless passing `-fms-compatibility` or using `clang-cl` as the driver and so I don't see why MSVC should dictate our behavior. (e.g., using clang and libc++ on Windows because the programmer doesn't want to use MSVC at all [except for the C runtime, I suppose] is something I believe we want to support, and with such a use case, defaulting to what MSVC defaults to seems surprising to me without other motivation.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131465/new/

https://reviews.llvm.org/D131465