RFC: Default language standard mode policy

[Nico Weber via cfe-commits]

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.

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.

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/4de48bc4/attachment.html>