<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 29, 2016 at 3:25 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Wed, Jun 29, 2016 at 12:14 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.</div></blockquote><div><br></div></span><div>Is that default something other than "the newest one"?</div></div></div></div></blockquote><div><br></div><div>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 <a href="https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/">https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/</a>)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>Note that at this point I'd like to mainly focus on what our policy should be;</div></div></div></div></blockquote><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> 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.</div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div><div>On Wed, Jun 29, 2016 at 3:09 PM, Richard Smith via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div><div dir="ltr"><div>Hi all!<br></div><div><br></div><div>I'd like to establish a policy for Clang's default language standard (if none is specified with -std), as follows:</div><div><br></div><div>  Clang defaults to the most recent published standard for the selected language that it fully implements.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>Thoughts?</div></div>
<br></div></div>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>