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

[Richard Smith]

Ping.

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>