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

[Eric Niebler via cfe-commits]

On 6/6/16, 3:58 PM, "metafoo at gmail.com on behalf of Richard Smith" <metafoo at gmail.com on behalf of richard at metafoo.co.uk> wrote:
>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 flavor
> of -iblah flag for the frontend. =(

I don’t know how we tell people to use –iblah for some system headers but –isystem for others. And if they don’t, we really have no way to tell, except by looking up each known header and noting the directory it’s found in. <barf>

\e