[cfe-dev] case-insensitive #include warning

[Eric Niebler via cfe-dev]

On 4/14/16, 1:14 PM, "Eric Niebler" <eniebler at fb.com> wrote:

>On 4/7/16, 4:44 PM, "Eric Niebler" <eniebler at fb.com> wrote:
>
>>On 4/7/16, 11:37 AM, "clattner at apple.com on behalf of Chris Lattner" <clattner at apple.com> 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>
>>
>>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.
>>
>>Eric
>
>
>I have reimplemented this feature with an eye to performance. I now have it down to 2-3% perf regression in the preprocessor, which I hope is acceptable. I have benchmarked perf on MacOS (with Cocoa.h), Linux (with all of Boost.Spirit), and Windows (with Windows.h). For the record, Windows.h is terrible about properly casing its #includes. :-)
>
>Incorrectly cased #includes are diagnosed on MacOS, Windows, and on Linux (for case-insensitive file systems). They are even diagnosed in Cygwin. They will not be diagnosed on *nix-like systems that don't have either F_GETPATH (like MacOS) or a mounted /proc filesystem.
>
>Comments welcome.
>
>Eric
>


Any thoughts about this patch? Are folks here still interested? (Sending updated patch with --ignore-space-change.)

\e

-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang.patch
Type: application/octet-stream
Size: 16316 bytes
Desc: clang.patch
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160419/91c904c4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm.patch
Type: application/octet-stream
Size: 4211 bytes
Desc: llvm.patch
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160419/91c904c4/attachment-0001.obj>