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

[Douglas Gregor]

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?

	- Doug