r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

[Richard Smith via cfe-commits]

On Mon, Jun 6, 2016 at 3:28 PM, Eric Niebler via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> On 6/3/16, 4:13 PM, "thakis at google.com on behalf of Nico Weber" <
> thakis at google.com on behalf of thakis at chromium.org> wrote:
> >On Fri, Jun 3, 2016 at 7:07 PM, Eric Niebler <eniebler at fb.com> wrote:
> >>On 6/3/16, 3:24 PM, "thakis at google.com on behalf of Nico Weber" <
> thakis at google.com on behalf of thakis at chromium.org> wrote:
> >>> On Fri, Jun 3, 2016 at 6:14 PM, Eric Niebler <eniebler at fb.com> wrote:
> >>>> I just checked, and warnings are not emitted from files in an
> -isystem path. I didn’t have to do anything special to get that behavior.
> >>>> I don’t know about -imsvc. Is that a clang-cl thing? I can’t say at
> this point why the diagnostics system treats -isystem and –imsvc
> >>>> differently.
> >>>>
> >>>> How about this: I can change the diagnostic to not warn about
> filenames if the file is found in a system include path, regardless of
> >>>> the location of the #include directive.
> >>>
> >>> That sounds like a good idea to me!
> >>
> >> On second thought, this warning isn’t living up to its potential if it
> doesn’t warn on `#include <IoStReAm>`. And if we don’t help people
> >> find misspellings of IOKIt, we haven’t done much good at all.
> >>
> >> Once I sort out the -imsvc thing, how bad would it be to leave it
> alone? Probably pretty bad for folks in the Windows world, huh?
> >
> > Yes, the warning is completely unusable there atm.
>
> Here’s my current thinking on the issue:
>
> 1) By default, warn only for user includes and the known standard headers
> (C/C++/posix).
> 2) Add an additional switch that controls warning for nonportable paths to
> system includes (disabled by default).
>
> Thoughts?


Rather than identifying specific known standard headers, could we instead
identify the directory containing the standard library implementation? We
know which one it is when we're initially forming the list of header search
directories. The downside is this probably means yet another flavour of
-iblah flag for the frontend. =(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160606/c6ad7f45/attachment-0001.html>