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

[Richard Smith]

On Thu, Jun 7, 2012 at 7:27 PM, Douglas Gregor <dgregor at apple.com> wrote:

>
> 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.
>

Great, r158418.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120613/5f3a9a28/attachment.html>