[cfe-dev] New warning for mismatched include case

[Jason Haslam]

On Jul 26, 2012, at 10:49 PM, Jason Haslam <jason.haslam at gmail.com> wrote:

> On Jul 24, 2012, at 3:56 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> 
>> On Jul 24, 2012, at 12:40 PM, Jason Haslam wrote:
>> 
>>> On Jul 23, 2012, at 7:00 PM, Chris Lattner wrote:
>>> 
>>>> 
>>>> On Jul 23, 2012, at 9:16 AM, Jason Haslam wrote:
>>>> 
>>>>> This updated patch adds a fixit and a test. The test fails on case-sensitive systems. Is it possible to test for an error on some platforms and a warning on others?
>>>> 
>>>> Very cool, it would be really great to get this warning.  However, there is high risks of slowing down compile times here, have you done any analysis of the compile-time cost of this?
>>> 
>>> I have done some performance testing. I see less than 1% slowdown over parts of LLVM. For example, I build the LLVMSupport library repeatedly until the build time becomes more-or-less consistent. Then do the same thing with the warning enabled. I don't know if there's a better way to test this.
>> 
>> This is with the warning enabled, right?  I haven't looked closely at the implementation yet, but you're doing entire directory scans to resolve the original case.  I'm not aware of a better way to find the original case, but this is very delicate.  It is not uncommon to include hundreds of headers in dozens of different directories.
> 
> I wrote a little script to generate a torture test for this warning like I proposed before.  It consists of a source file with 4096 different #includes in 64 directories where each directory contains an additional 4096 files. As expected, it is many times slower with the warning enabled than without on the existing implementation. It goes from .08 seconds without the warning up to 5 seconds with the warning.
> 
> I also tried the readdir caching optimization that I mentioned before. It brings the time with the warning down to .35 seconds. On real code it's still well below 1% difference. So what do you think? Is this just too risky to add? Updated patch is attached.

Ugh! Ignore the previous patch. This one actually works correctly.

Jason

-------------- next part --------------
A non-text attachment was scrubbed...
Name: include-case.diff
Type: application/octet-stream
Size: 5789 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120727/eaef445a/attachment.obj>
-------------- next part --------------