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

[Eric Fiselier via cfe-commits]

On Thu, Oct 4, 2018 at 11:42 AM Richard Smith via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> 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.
>

+1

I was going to suggest this exact fix. (But only in the case of <version>
and not as a general rule going forward.)




>
> 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
>>
> _______________________________________________
> 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/1f8d9726/attachment.html>