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

[Marshall Clow via cfe-commits]

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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20181004/41d2abaf/attachment.html>