[cfe-commits] [PATCH] Overriding system-header-ness based on #include path

[Douglas Gregor]

On Jun 7, 2012, at 6:27 PM, Richard Smith wrote:

> On Thu, Jun 7, 2012 at 5:12 PM, Douglas Gregor <dgregor at apple.com> 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.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120607/5cff8443/attachment.html>