On Jun 7, 2012, at 6:27 PM, Richard Smith wrote:
> On Thu, Jun 7, 2012 at 5:12 PM, Douglas Gregor <[email protected]> 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.
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
