<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 8, 2016 at 1:56 PM, Eric Niebler <span dir="ltr"><<a href="mailto:eniebler@fb.com" target="_blank">eniebler@fb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(adding back cfe-commits, answers inline)<br>
<span class=""><br>
On 6/8/16, 10:11 AM, "<a href="mailto:thakis@google.com">thakis@google.com</a> on behalf of Nico Weber" <<a href="mailto:thakis@google.com">thakis@google.com</a> on behalf of <a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:<br>
>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.)<br>
><br>
>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?<br>
<br>
</span>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.<br></blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>Eric, do you think you could send Stephan a list of #includes in Windows headers that would need changing?<br>
<br>
</span>Since warnings are not emitted from within system headers, and since badly-cased #includes of WinSDK headers will no longer warn by default, is this still an issue? I don’t have an easy way to generate this list.<br>
<span class=""><br>
>(any reason cfe-commits got dropped from the cc list? This would be good to discuss on-thread.)<br>
><br>
>On Tue, Jun 7, 2016 at 6:42 PM, Stephan T. Lavavej <<a href="mailto:stl@exchange.microsoft.com">stl@exchange.microsoft.com</a>> wrote:<br>
>>Knowing Windows, there is probably no way that they would change the case on disk on the headers, as that would be observable to directory enumeration.<br>
>> <br>
>>STL<br>
>> <br>
>>From: <a href="mailto:thakis@google.com">thakis@google.com</a> [mailto:<a href="mailto:thakis@google.com">thakis@google.com</a>] On Behalf Of Nico Weber<br>
>>Sent: Tuesday, June 7, 2016 3:40 PM<br>
>>To: Stephan T. Lavavej <<a href="mailto:stl@exchange.microsoft.com">stl@exchange.microsoft.com</a>><br>
>>Cc: Eric Niebler <<a href="mailto:eniebler@fb.com">eniebler@fb.com</a>>; Taewook Oh <<a href="mailto:twoh@fb.com">twoh@fb.com</a>><br>
>>Subject: Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.<br>
>> <br>
>>>STL: "Make sure all filenames have lower-case names and all #includes refer to them by lower-case name, and tell all users to include files by lower case" is probably the only SDK change that's simple enough that it has a chance to be understood and to actually happen. (The other alternative is >>>"commit to keep the case of each SDK header as-is forever, and ask every client to use the on-disk casing, which unless they use a compiler with a warning like this they'll have to look up themselves" -- and at the moment I think the on-disk case of windows.h is Windows.h while every program I >>>know of includes it as <windows.h>, so this would require changing decades of existing code.)<br>
>>> <br>
>>>On Tue, Jun 7, 2016 at 12:57 PM, Stephan T. Lavavej <<a href="mailto:stl@exchange.microsoft.com">stl@exchange.microsoft.com</a>> wrote:<br>
>>>>Sure, but it's time consuming to figure out a build, and I have a limited amount of time to donate.<br>
>>>><br>
>>>>On the other hand, if this gets into trunk and eventually Clang/C2, at that point auditing the headers would be pretty easy over here.<br>
>>>><br>
>>>>STL<br>
>>>><br>
>>>>-----Original Message-----<br>
>>>>From: Eric Niebler [mailto:<a href="mailto:eniebler@fb.com">eniebler@fb.com</a>]<br>
>>>>Sent: Tuesday, June 7, 2016 9:00 AM<br>
>>>>To: Stephan T. Lavavej <<a href="mailto:stl@exchange.microsoft.com">stl@exchange.microsoft.com</a>>; Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>><br>
>>>>Cc: Taewook Oh <<a href="mailto:twoh@fb.com">twoh@fb.com</a>><br>
>>>>Subject: Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.<br>
>>>><br>
</span>>>>>>Someone who builds and distributes their own mingw distribution can figure out how to build clang. ☺ The directions are here: <a href="http://clang.llvm.org/get_started.html" rel="noreferrer" target="_blank">http://clang.llvm.org/get_started.html</a>. I’m happy to answer any questions.<br>
<span class="">>>>>><br>
>>>>>\e<br>
>>>>><br>
>>>>>On 6/6/16, 5:54 PM, "Stephan T. Lavavej" <<a href="mailto:stl@exchange.microsoft.com">stl@exchange.microsoft.com</a>> wrote:<br>
>>>>>>Unfortunately, I haven't figured out how to build Clang/LLVM (all of my Clang work is with Clang/C2 which they build for me).<br>
>>>>>><br>
>>>>>>STL<br>
>>>>>><br>
>>>>>>-----Original Message-----<br>
>>>>>>From: Eric Niebler [mailto:<a href="mailto:eniebler@fb.com">eniebler@fb.com</a>]<br>
>>>>>>Sent: Monday, June 6, 2016 3:19 PM<br>
>>>>>>To: Stephan T. Lavavej <<a href="mailto:stl@exchange.microsoft.com">stl@exchange.microsoft.com</a>>; Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>><br>
>>>>>>Cc: Taewook Oh <<a href="mailto:twoh@fb.com">twoh@fb.com</a>><br>
>>>>>>Subject: Re: r271708 - Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.<br>
>>>>>><br>
>>>>>>On 6/3/16, 5:17 PM, "Stephan T. Lavavej" <<a href="mailto:stl@exchange.microsoft.com">stl@exchange.microsoft.com</a>> wrote:<br>
>>>>>>> [Eric Niebler]<br>
>>>>>>>> Once I sort out the -imsvc thing, how bad would it be to leave it alone?<br>
>>>>>>>> Probably pretty bad for folks in the Windows world, huh?<br>
>>>>>>><br>
>>>>>>> If you can send me an explicit list of WinSDK headers that are including things with the wrong case, I can send it to Windows - they are committed to cleaning up the WinSDK in order to make it friendlier to other tools.<br>
>>>>>>><br>
>>>>>>> Note that we can't go back in time and fix the shipped SDKs, though.<br>
>>>>>><br>
>>>>>>It would actually be easier for you to generate this list than for me since I’m not set up to build anything with the Windows SDK. Check out the llvm/clang sources and apply the two linked patches. Configure and build. Then just use clang as normal and watch the warnings roll.<br>
>>>>>><br>
</span>>>>>>><a href="http://reviews.llvm.org/D19842" rel="noreferrer" target="_blank">http://reviews.llvm.org/D19842</a><br>
>>>>>><a href="http://reviews.llvm.org/D19843" rel="noreferrer" target="_blank">http://reviews.llvm.org/D19843</a><br>
<div class="HOEnZb"><div class="h5">>>>>>><br>
>>>>>>The warnings tell you exactly what to change the #include to, so this should be easy pickin’s.<br>
>>>>>><br>
>>>>>>Eric<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>