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

Richard Smith richard at metafoo.co.uk
Thu Jun 7 18:27:02 PDT 2012

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

More information about the cfe-commits mailing list