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

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to