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

Wed Jun 8 11:12:00 PDT 2016

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.

> >Eric, do you think you could send Stephan a list of #includes in Windows
> headers that would need changing?
>
> 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.
>
> >(any reason cfe-commits got dropped from the cc list? This would be good
> to discuss on-thread.)
> >
> >On Tue, Jun 7, 2016 at 6:42 PM, Stephan T. Lavavej <
> stl at exchange.microsoft.com> wrote:
> >>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.
> >>
> >>STL
> >>
> >>From: thakis at google.com [mailto:thakis at google.com] On Behalf Of Nico
> Weber
> >>Sent: Tuesday, June 7, 2016 3:40 PM
> >>To: Stephan T. Lavavej <stl at exchange.microsoft.com>
> >>Cc: Eric Niebler <eniebler at fb.com>; Taewook Oh <twoh at fb.com>
> >>Subject: Re: r271708 - Use the name of the file on disk to issue a new
> diagnostic about non-portable #include and #import paths.
> >>
> >>>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.)
> >>>
> >>>On Tue, Jun 7, 2016 at 12:57 PM, Stephan T. Lavavej <
> stl at exchange.microsoft.com> wrote:
> >>>>Sure, but it's time consuming to figure out a build, and I have a
> limited amount of time to donate.
> >>>>
> >>>>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.
> >>>>
> >>>>STL
> >>>>
> >>>>-----Original Message-----
> >>>>From: Eric Niebler [mailto:eniebler at fb.com]
> >>>>Sent: Tuesday, June 7, 2016 9:00 AM
> >>>>To: Stephan T. Lavavej <stl at exchange.microsoft.com>; Nico Weber <
> thakis at chromium.org>
> >>>>Cc: Taewook Oh <twoh at fb.com>
> >>>>Subject: Re: r271708 - Use the name of the file on disk to issue a new
> diagnostic about non-portable #include and #import paths.
> >>>>
> >>>>>Someone who builds and distributes their own mingw distribution can
> figure out how to build clang. ☺ The directions are here:
> http://clang.llvm.org/get_started.html. I’m happy to answer any questions.
> >>>>>
> >>>>>\e
> >>>>>
> >>>>>On 6/6/16, 5:54 PM, "Stephan T. Lavavej" <stl at exchange.microsoft.com>
> wrote:
> >>>>>>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).
> >>>>>>
> >>>>>>STL
> >>>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: Eric Niebler [mailto:eniebler at fb.com]
> >>>>>>Sent: Monday, June 6, 2016 3:19 PM
> >>>>>>To: Stephan T. Lavavej <stl at exchange.microsoft.com>; Nico Weber <
> thakis at chromium.org>
> >>>>>>Cc: Taewook Oh <twoh at fb.com>
> >>>>>>Subject: Re: r271708 - Use the name of the file on disk to issue a
> new diagnostic about non-portable #include and #import paths.
> >>>>>>
> >>>>>>On 6/3/16, 5:17 PM, "Stephan T. Lavavej" <stl at exchange.microsoft.com>
> wrote:
> >>>>>>> [Eric Niebler]
> >>>>>>>> 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?
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> Note that we can't go back in time and fix the shipped SDKs,
> though.
> >>>>>>
> >>>>>>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.
> >>>>>>
> >>>>>>http://reviews.llvm.org/D19842
> >>>>>>http://reviews.llvm.org/D19843
> >>>>>>
> >>>>>>The warnings tell you exactly what to change the #include to, so
> this should be easy pickin’s.
> >>>>>>
> >>>>>>Eric
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160608/3d0952b8/attachment-0001.html>