RFC: Default language standard mode policy

Nico Weber via cfe-commits cfe-commits at lists.llvm.org
Wed Jun 29 12:47:04 PDT 2016


On Wed, Jun 29, 2016 at 3:25 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

> On Wed, Jun 29, 2016 at 12:14 PM, Nico Weber <thakis at chromium.org> wrote:
>
>> For clang-cl, we should follow cl's model of selecting a standard. Before
>> C++17, this was "use newest language the compiler knows about" (keyed off
>> -fmsc-version; clang-cl detects the system msvc version by default if
>> that's not passed in). After C++17, there's an explicit language flag, and
>> we use the same default as cl.
>>
>
> Is that default something other than "the newest one"?
>

It looks like the next MSVC (which adds that flag) defaults to C++14. (See
majnemer's r273841 which implemented this in clang-cl, and
https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/
)


> Last I checked (which was a while ago), libstdc++ didn't parse with
>> -std=c++14, at least at some version. I don't remember which version of
>> libstdc++ I tried (maybe 4.9?). Should that factor into the decision? Not
>> parsing standard library headers by default on Linux seems like a somewhat
>> suboptimal user experience.
>>
>
> Last time I looked into this, I saw only one problem with version 4.9:
> libc doesn't provide ::gets to C++14, and earlier versions of libstdc++
> assume it's there and do "namespace std { using ::gets; }". We can add a
> compatibility hack to clang to work around this.
>
> Note that at this point I'd like to mainly focus on what our policy should
> be;
>

Fair enough. I don't have a strong opinion on that; your proposal makes
sense to me. (Except for clang-cl, which I think needs to mirror what cl
does.)


> there are certainly technical challenges involved in actually applying the
> policy (another one is that clang's test suite still has some failures when
> the default is changed, but Charles Li has made tremendous headway on
> this), and if we can't actually prepare for the transition in the C++
> default in time for 3.9, then so be it.
>
>
>> On Wed, Jun 29, 2016 at 3:09 PM, Richard Smith via cfe-commits <
>> cfe-commits at lists.llvm.org> wrote:
>>
>>> Hi all!
>>>
>>> I'd like to establish a policy for Clang's default language standard (if
>>> none is specified with -std), as follows:
>>>
>>>   Clang defaults to the most recent published standard for the selected
>>> language that it fully implements.
>>>
>>> The practical impact of this is that clang++ will default to C++14 for
>>> C++ compilations (for version 3.9 onwards) and will default to C++17 once
>>> our implementation support is complete and the standard is published
>>> (whichever happens later).
>>>
>>> I'd suggest that we apply the same policy for clang-cl, but if it's
>>> important that we enable a not-yet-fully-implemented standard for cl
>>> compatibility, that seems reasonable.
>>>
>>> The question of whether the default mode for the GCC-compatible driver
>>> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
>>> discussing. Enabling GNU keywords by default is a very odd choice, and if
>>> we believe we can change our defaults without breaking the world then this
>>> seems like a good time to do so.
>>>
>>> I also intend to make explicit in our documentation that our -std=XXX
>>> flag enables the selected standard, *plus all relevant issues in Defect
>>> Report status from the relevant language committee* (it doesn't make sense
>>> to support a language without its bugfixes).
>>>
>>> Thoughts?
>>>
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160629/1c488c42/attachment.html>


More information about the cfe-commits mailing list