[cfe-dev] RFC: Default language standard mode policy

[Richard Smith via cfe-commits]

On Wed, Jun 29, 2016 at 12:55 PM, Hal Finkel via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

>
> ------------------------------
>
> *From: *"Richard Smith via cfe-commits" <cfe-commits at lists.llvm.org>
> *To: *"cfe-commits" <cfe-commits at lists.llvm.org>, "Clang Dev" <
> cfe-dev at lists.llvm.org>
> *Sent: *Wednesday, June 29, 2016 2:09:37 PM
> *Subject: *RFC: Default language standard mode policy
>
> 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 think that we need to include libc++ in this criteria as well. I think
> we'll also need some CMake flags to adjust the default for builds for
> systems on which this won't work.
>

Right, it doesn't make sense to change our default in a way that breaks use
of the same version of libc++, or a supported version of libstdc++ (and we
should establish how old a version of libstdc++ we support here).

However, I don't immediately see that we need to wait for libc++ to be
feature-complete before we enable the new standard in Clang. If that's what
you're suggesting, can you expand on why? We already have the SD-6 feature
test macros to test for implementation of specific features.

> 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.
>
> Unfortunately, on many systems, some standard system headers won't even
> parse without GNU extensions enabled. I think we'll need to leave the GNU
> extensions on by default (at least for parsing system headers).
>

Can you give an example? -std=c++11 works fine on a broad range of systems.
Note that this is not about GNU *extensions*, which are enabled in both
modes; it's about GNU *keywords* (and a small number of non-conforming
extensions) -- in particular, the 'typeof' GNU keyword, and support for the
asm keyword in C and the inline keyword in C89 (without __decoration__).

> 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).
>
> +1
>
>  -Hal
>
>
> Thoughts?
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160629/80b1fcbf/attachment.html>