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/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?

\e