This is a patch for PR31836. As the bug replaces the path separators in the included file name with the characters following them, the test script makes sure that there's no "Ccase-insensitive-include-pr31836.h" in the warning message.
Details
Diff Detail
- Build Status
Buildable 4007 Build 4007: arc lint + arc unit
Event Timeline
lib/Lex/PPDirectives.cpp | ||
---|---|---|
1983 | What happens on Windows for an absolute path like "C:/hello/world.h", I wonder? Does this correctly generate the fixit? @karies? | |
test/Lexer/case-insensitive-include-pr31836.sh | ||
8 | @twoh I'm curious why you chose to check that the output was not a specific incorrect answer instead of checking that the output was the correct answer. |
Make it explicit that the test doesn't support windows. @eric_niebler, my original intention was avoiding use of platform-dependent path separator, but now made it explicit that the test is not for windows, it should be okay to use '/'. Thanks for the comments!
My question was more about whether the code is correct for absolute paths on Windows, not about whether this particular test would pass or fail. Have you tested an incorrectly-cased absolute path on a Windows machine?
@eric_niebler I just tried it on Windows machine, and it just succeeded with no warnings/fix-it. Is that expected?
lib/Lex/PPDirectives.cpp | ||
---|---|---|
1983 | I also cannot reproduce this diag on Windows, likely because NTFS and FAT are case indifferent (not preserving like MacOS) so the file system cannot reply with "this is how *I* would have spelled the file name". |
test/Lexer/case-insensitive-include-pr31836.sh | ||
---|---|---|
7 | This is an unsupported test on Linux because of REQUIRES: case-insensitive-filesystem. |
@eric_niebler Do you want any more experiments with this patch? I think Windows machines not printing warnings/fixits for absolute path is a separate issue with this.
What happens on Windows for an absolute path like "C:/hello/world.h", I wonder? Does this correctly generate the fixit? @karies?