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
