On Thu, Jun 7, 2012 at 7:27 PM, Douglas Gregor <[email protected]> wrote:
> > On Jun 7, 2012, at 6:27 PM, Richard Smith wrote: > > On Thu, Jun 7, 2012 at 5:12 PM, Douglas Gregor <[email protected]> wrote: > >> >> On May 22, 2012, at 3:36 PM, Richard Smith wrote: >> >> > Hi, >> > >> > Some popular open-source projects have a code layout which looks >> something like this: >> > >> > project/ >> > libs/ >> > some_third_party_lib/ >> > my_own_lib/ >> > foo/my_code/ >> > bar/my_code/ >> > >> > ... with a single include path pointing at the root of the project. >> When rolling out new warnings to such projects, warnings in the project's >> own code should be fixed, and warnings in third-party headers should >> typically be ignored. However, this is currently hard to achieve. >> > >> > The natural way to suppress warnings from third-party headers would be >> to treat them as system headers, but we only have two ways to achieve this: >> -isystem (which doesn't work for this file layout), and #pragma >> system_header (which requires updating *all* the third_party headers). >> Neither of these seems to be a good solution to the problem. >> > >> > The attached patch addresses this by adding two command-line arguments: >> -isystem-prefix FOO/ treats all #include "FOO/..." directives as including >> a system header, and -ino-system-prefix FOO/BAR/ treats all #include >> "FOO/BAR/..." directives as not including a system header. The >> latest-specified argument wins, and the overrides only apply to files which >> are found relative to a header search path (and not ones which are found >> relative to the current file, or by absolute path). >> > >> > Is this OK for mainline Clang? The implementation is currently not >> optimized for the case of large numbers of such arguments -- we can deal >> with that later if it becomes an issue. >> >> We had run into precisely this problem at the framework level and (fairly >> recently) added a framework-only hack that allows a framework's headers to >> be treated as system headers. It was a kludge; your solution seems somewhat >> more general. >> >> I was a little surprised to see that it's based on the style of include >> (<Foo/>) rather than on a particular subdirectory. Was that a specific >> design decision or was it a more expedient implementation approach? >> > > It was deliberate: if the system header area contains a symlink which > leads out of the system header area, then we want files found through that > symlink to still be treated as system headers. Thus the check is based on > how the #include line is written, rather than where the located file lives > within the file system. I considered a mechanism for attaching the prefixes > to specific include paths (to make them more akin to specifying a > directory), but I was reluctant to add such complexity without a motivating > use case; the source file names for a #include directive are a single > global namespace anyway (at least in the case where the file is found via > an include path). > > > Okay, that makes sense. > Great, r158418.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
