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/8/16, 11:12 AM, "thakis at google.com on behalf of Nico Weber" <thakis at google.com on behalf of thakis at chromium.org> wrote:
>On Wed, Jun 8, 2016 at 1:56 PM, Eric Niebler <eniebler at fb.com> wrote:
>>
>>(adding back cfe-commits, answers inline)
>>
>>On 6/8/16, 10:11 AM, "thakis at google.com on behalf of Nico Weber" <thakis at google.com on behalf of thakis at chromium.org> wrote:
>>>Sounds like "commit to the current file case and fix all the world's includes" then :-) (MinGW's windows headers have different case than MSVC's, making this extra annoying.)
>>>
>>>Maybe this warning could be keyed off -fmsc-version in clang-cl then and only be enabled there once a future MSVC with headers where this is fixed has been deployed and is picked via -fmsc-version?
>>
>>I just changed the patch so that #includes to headers found in system include paths do not trigger this warning by default (unless the header is a known “portable” header – i.e., standard C/C++/Posix or Boost headers). This shouldn’t be an issue anymore.
>
>Well, it'd be nice if the warning would fire everywhere and everyone got their cases right – then a project that builds on a case-insensitive file system should compile fine if it's moved to a case-sensitive one.

Sure, that’d be nice. And folks who really care can get that with my patch by flipping –Wnonportable-system-include-path; it’s just not the default. You could think of this patch as a staged rollout of the feature.

\e