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

Richard Smith richard at metafoo.co.uk
Tue May 29 13:56:08 PDT 2012


On Tue, May 22, 2012 at 3:36 PM, Richard Smith <richard at metafoo.co.uk>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.
> Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120529/87aef671/attachment.html>

More information about the cfe-commits mailing list