<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Oct 3, 2018 at 3:38 AM Christof Douma <<a href="mailto:Christof.Douma@arm.com">Christof.Douma@arm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple">
<div class="m_-5745704915874538680WordSection1">
<p class="MsoNormal">Hi.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Yes, including <utility> would try to include the “version” file inside the users project. The problem is not the existence of the header file, but the #include directive that is not guarded. To give examples on when this goes wrong:
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">A project uses VERSION in their source directory to hold some version string used in the build system. On platforms like Windows and OS X this file is indistinguishable from the system include file that many headers include.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I don’t think this is a strange setup, and while I expect that for C++20 code bases, people need to pick a different name, I think that existing projects should not be bothered by this. It would be nice if everybody was using -iquote, or
better in my opinion, that -I was behaving like -iquote. But a fix that we can apply now is to use:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> #if _LIBCPP_STD_VER > 17<u></u><u></u></p>
<p class="MsoNormal"> #include <version><u></u><u></u></p>
<p class="MsoNormal"> #endif<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Would that be acceptable?</p></div></div></blockquote><div><br></div><div>Christof -</div><div><br></div><div>There are people in the community who really want these feature macros.</div><div>In particular, they *really* want them for C++14 and C++17 (not just c++20)</div><div><br></div><div>In general, I am against back-porting new features to old language versions (string_view being the one large exception), but this seems like a low-risk thing to do.</div><div><br></div><div>However, it would make your suggestion unfeasible.</div><div><br></div><div>-- Marshall</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div class="m_-5745704915874538680WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal">Christof<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>><br>
<b>Date: </b>Tuesday, 2 October 2018 at 19:52<br>
<b>To: </b>Christof Douma <<a href="mailto:Christof.Douma@arm.com" target="_blank">Christof.Douma@arm.com</a>><br>
<b>Cc: </b>Marshall Clow <<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>>, cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>>, nd <<a href="mailto:nd@arm.com" target="_blank">nd@arm.com</a>><br>
<b>Subject: </b>Re: [libcxx] r342073 - Implement the infrastructure for feature-test macros. Very few actual feature test macros, though. Reviewed as: <a href="https://reviews.llvm.org/D51955" target="_blank">https://reviews.llvm.org/D51955</a><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">On Tue, Oct 2, 2018 at 1:33 PM Christof Douma via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-left:36.0pt">Hi Marshall.<br>
<br>
I think that this patch breaks backwards compatibility. Assumes that the header file "version" is used by C++ projects that use a C++ standard that did not specify a 'version' header. Many toolchains will put search paths specified with -I in front of the
system search path. The result is that the application header file is included whenever a standard header file is included. That is unexpected and can break builds.<br>
<br>
Do you agree this is an issue or do you consider this an issue with the way toolchains handle include search paths?<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">If I understand correctly, you have user code which provides a header called "version", and now when files like <utility> include <version> they pick up the user header instead of the STL one?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Are you specifying custom libc++ include paths when this occurs? Or just passing "-stdlib=libc++" and letting the compiler do the rest?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">In general, I don't consider this a bug. There is no way for libc++ to make the <version> file disappear in older dialects, and libc++ headers are free to include w/e additional headers<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">they need.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><u></u><br></p></div></div></div></div></div></blockquote></div></div>