[cfe-dev] case-insensitive #include warning

[Jason Haslam via cfe-dev]

> On Apr 7, 2016, at 5:44 PM, Eric Niebler via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> On 4/7/16, 11:37 AM, "clattner at apple.com <mailto:clattner at apple.com> on behalf of Chris Lattner" <clattner at apple.com <mailto:clattner at apple.com>> wrote:
> 
> 
>> On Apr 5, 2016, at 4:03 PM, Eric Niebler via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>> 
>> Hi all,
>> 
>> I have an initial cut at patch that issues a warning when a file is #included on a case-insensitive file system that would not be found on a case-sensitive system. Is there interest?
>> 
>> Since this is a hard problem to solve perfectly, I have opted for a strategy that is efficient and conservative about issuing diagnostics. That is, it shouldn't give false positives, but it will fail to diagnose some non-portable paths. On *nix systems, the low-level APIs that stat and open files get an extra call to ::realpath, and the result is cached along with the rest of the file metadata. On Windows, I use a combination of GetFullPathName and GetLongPathName to get the same effect. (I don't believe that's guaranteed to get the physical name including case, but it seems to mostly work in my testing.)
>> 
>> Due to how I compare path components, a relative path like "NoTtHeRiGhTcAsE/../correctly-cased.h" will not be diagnosed, but "../NoTtHeRiGhTcAsE/correctly-cased.h" will be. Catching more cases requires many more round trips to the disk, which I wanted to avoid.
> 
> Hi Eric,
> 
> This would be a hugely welcomed feature, but have you done any performance analysis of this?  The preprocessor and the data structures you are touching are very sensitive.
> 
> You can stress test the preprocessor by using the "clang -cc1 -Eonly” mode.  If you’re on a mac, I’d recommend timing <Cocoa/Cocoa.h>
> 
> 
> Thanks for the suggestion, Chris. Looks like I've regressed the speed of the preprocessor by 25%. Yikes. I'll see what I can do.

I was working on a similar patch a few years ago (http://lists.llvm.org/pipermail/cfe-dev/2012-July/023090.html <http://lists.llvm.org/pipermail/cfe-dev/2012-July/023090.html> is the start of a very long thread). Does realpath really give the real case on unix? My understanding is that it doesn’t. I had to resort to reading the directory listings and comparing entries. And of course readdir is even slower. I could only ever get decent performance by aggressively caching the directory listings. In the end it got too complicated and wasn’t entirely convinced that performance would ever be good enough to warrant the addition. I was mostly interested in Mac though. Maybe it’s a different story on Windows.

Jason

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160411/91f34b04/attachment.html>