[libcxx] r342073 - Implement the infrastructure for feature-test macros. Very few actual feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955

[Richard Smith via cfe-commits]

Perhaps libc++ could provide a __version file that contains the headers,
and use #include <__version> internally? We'd still need a <version> header
that just includes <__version> for conformance, but that should be after
user headers on the include path so shouldn't break things.

On Thu, 4 Oct 2018, 07:10 Marshall Clow via cfe-commits, <
cfe-commits at lists.llvm.org> wrote:

> On Wed, Oct 3, 2018 at 3:38 AM Christof Douma <Christof.Douma at arm.com>
> wrote:
>
>> Hi.
>>
>>
>>
>> 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:
>>
>>
>>
>> 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.
>>
>>
>>
>> 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:
>>
>>
>>
>>   #if _LIBCPP_STD_VER > 17
>>
>>     #include <version>
>>
>>   #endif
>>
>>
>>
>> Would that be acceptable?
>>
>
> Christof -
>
> There are people in the community who really want these feature macros.
> In particular, they *really* want them for C++14 and C++17 (not just c++20)
>
> 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.
>
> However, it would make your suggestion unfeasible.
>
> -- Marshall
>
>
>
>
>>
>>
>> Thanks,
>>
>> Christof
>>
>>
>>
>> *From: *Eric Fiselier <eric at efcs.ca>
>> *Date: *Tuesday, 2 October 2018 at 19:52
>> *To: *Christof Douma <Christof.Douma at arm.com>
>> *Cc: *Marshall Clow <mclow.lists at gmail.com>, cfe-commits <
>> cfe-commits at lists.llvm.org>, nd <nd at arm.com>
>> *Subject: *Re: [libcxx] r342073 - Implement the infrastructure for
>> feature-test macros. Very few actual feature test macros, though. Reviewed
>> as: https://reviews.llvm.org/D51955
>>
>>
>>
>>
>>
>> On Tue, Oct 2, 2018 at 1:33 PM Christof Douma via cfe-commits <
>> cfe-commits at lists.llvm.org> wrote:
>>
>> Hi Marshall.
>>
>> 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.
>>
>> Do you agree this is an issue or do you consider this an issue with the
>> way toolchains handle include search paths?
>>
>>
>>
>> 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?
>>
>> Are you specifying custom libc++ include paths when this occurs? Or just
>> passing "-stdlib=libc++" and letting the compiler do the rest?
>>
>>
>>
>> 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
>>
>> they need.
>>
>>
>> _______________________________________________
> 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/20181004/6c5d7cf2/attachment.html>