RFC: Default language standard mode policy

[Richard Smith via cfe-commits]

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"?

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; 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/df321296/attachment.html>