[cfe-dev] New warning for mismatched include case

[Michael Spencer]

On Tue, Jul 24, 2012 at 2: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.
>
> -Chris
>

Also make sure you are testing the -fsyntax-only speed. This matters
quite a bit for IDE integration.

I attempted to implement this feature a while ago but ran into the
problem of finding a sane way to get the original case including
parent directories. Most of the time you have to recursively iterate
directories, which you almost do.  On Windows you can actually do
GetLongName(GetShortName(path)). This is a lot faster and will work
most of the time, but it doesn't work everywhere.

For my case I actually needed it specifically on Linux as I keep my
source code on Windows and compile on both platforms. NTFS mounted on
Linux is still case insensitive. I've actually broken the build a few
times because of this :(.

- Michael Spencer