On Thu, Oct 4, 2018 at 11:42 AM Richard Smith via cfe-commits < cfe-commits@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@lists.llvm.org> wrote: > >> On Wed, Oct 3, 2018 at 3:38 AM Christof Douma <christof.do...@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 <e...@efcs.ca> >>> *Date: *Tuesday, 2 October 2018 at 19:52 >>> *To: *Christof Douma <christof.do...@arm.com> >>> *Cc: *Marshall Clow <mclow.li...@gmail.com>, cfe-commits < >>> cfe-commits@lists.llvm.org>, nd <n...@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@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@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> > _______________________________________________ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits