[cfe-dev] case-insensitive #include warning

[Jonathan Coe via cfe-dev]

Reposting this to the list (replied to sender by mistake):

Jonathan Coe:  I wonder if a clang-tidy check might be a good place for a
more exhaustive check?

Eric N: That's not a bad idea, thanks. I would still like to leave this
simple check in to catch the majority of the cases, since not everybody
uses clang-tidy. Do you have thoughts on the patch?

On 7 April 2016 at 19:49, John Sully via cfe-dev <cfe-dev at lists.llvm.org>
wrote:

> Out of curiosity have you tried this with some of the more interesting
> upper/lower case pairs like the turkish 'İ'?
>
> It sounds like the way you're achieving this should allow this to work,
> but its worthwhile to try it.
>
> On Thu, Apr 7, 2016 at 11:37 AM, Chris Lattner via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>>
>> On Apr 5, 2016, at 4:03 PM, Eric Niebler via cfe-dev <
>> 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>
>>
>> -Chris
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160407/cc37bbad/attachment.html>