<br><br><div class="gmail_quote">On Mon, Jul 23, 2012 at 6:16 PM, Jason Haslam <span dir="ltr"><<a href="mailto:jason.haslam@gmail.com" target="_blank">jason.haslam@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
<span class="HOEnZb"><font color="#888888"><br>
Jason<br></font></span></blockquote><div><br>There is a preprocessor directive to test for the presence of include files: __has_include I think.<br><br>#if __has_include(<IOSTREAM>)<br>#  include <IOSTREAM><br>
#endif<br><br>should make it so that the #include is only processed on file systems where <IOSTREAM> was found (which excludes case-sensitives file systems).<br><br>-- Matthieu<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888">
<br>
</font></span><br><br>
<br>
<br>
On Jul 19, 2012, at 11:58 PM, Jason Haslam wrote:<br>
<br>
> Okay, I added caching which improved performance some. I also changed it to only check in user code, which made the Cocoa.h test case moot. I've run the attached patch over real code from LLVM and I don't see any measurable performance difference. It still may be worth disabling the check on case-sensitive file systems, although I'm not entirely sure how to do that beyond "#if defined(__APPLE__) || defined(_WIN32)".<br>

><br>
> If this looks like the right direction then I'll try to address some of the other concerns.<br>
><br>
> Jason<br>
><br>
> <include_case.diff><br>
><br>
><br>
> On Jul 18, 2012, at 11:26 PM, Jason Haslam wrote:<br>
><br>
>> Yes, performance is definitely an issue. I see about 30% degradation on Cocoa.h with this naive implementation. That's probably not going to fly under any circumstance. I'll take a closer look...<br>
>><br>
>> Jason<br>
>><br>
>><br>
>> On Jul 18, 2012, at 5:12 PM, Ted Kremenek wrote:<br>
>><br>
>>> Hi Jason,<br>
>>><br>
>>> Any idea what is the performance impact of this change?  My concern that this is potentially expensive, and we shouldn't be performing the check on a case-sensitve file system (if we can help it).  That said, many people have requested this kind of checking, so I'm happy to see you taking a stab at it.<br>

>>><br>
>>> Ted<br>
>>><br>
>>> On Jul 18, 2012, at 3:09 PM, Jason Haslam <<a href="mailto:jason.haslam@gmail.com">jason.haslam@gmail.com</a>> wrote:<br>
>>><br>
>>>> The attached (incomplete proof-of-concept) patch provides a new warning that fires on case-insensitive file systems when the case of the file name in the #include directive doesn't match the case of the file name on disk. The idea is to avoid broken commits that fail to build on case-sensitive file systems. For example:<br>

>>>><br>
>>>> jason$ ls<br>
>>>> test.cpp test.h<br>
>>>> jason$ cat test.cpp<br>
>>>> #include "Test.h"<br>
>>>> jason$ clang++ -fsyntax-only test.cpp<br>
>>>> test.cpp:1:10: warning: include case does not match the case of the file on disk<br>
>>>> #include "Test.h"<br>
>>>>      ^<br>
>>>> 1 warning generated.<br>
>>>><br>
>>>> What do you think? Is this desirable? Does the direction look right?<br>
>>>><br>
>>>> Jason<br>
>>>><br>
>>>> <include_case.diff>_______________________________________________<br>
>>>> cfe-dev mailing list<br>
>>>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>>><br>
>><br>
><br>
<br>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br>