forked from OSchip/llvm-project
![]() The approach in D30000 assumes that the '/' returned by path::begin() is the first element for absolute paths, but that's not true on Windows. Also, on Windows backslashes in include lines often end up escaped so that there are two of them. Having backslashes in include lines is undefined behavior in most cases and implementation-defined behavior in C++20, but since clang treats it as normal repeated path separators, the diagnostic should too. Unbreaks -Wnonportable-include-path for absolute paths on Windows, and unbreaks it on non-Windows in the case of absolute paths with repeated directory separators. This affects e.g. the `#include __FILE__` technique if the file passed to clang has the wrong case for the drive letter. Before: C:\src\llvm-project>bin\clang-cl.exe c:\src\llvm-project\test.cc c:\\src\\llvm-project\\test.cc(4,10): warning: non-portable path to file '"c\\srccllvm-projectctest.cc.'; specified path differs in case from file name on disk [-Wnonportable-include-path] ^ Now: C:\src\llvm-project> out\gn\bin\clang-cl c:\src\llvm-project\test.cc c:\\src\\llvm-project\\test.cc(4,10): warning: non-portable path to file '"C:\\src\\llvm-project\\test.cc"'; specified path differs in case from file name on disk [-Wnonportable-include-path] ^ Differential Revision: https://reviews.llvm.org/D79223 |
||
---|---|---|
.. | ||
CMakeLists.txt | ||
DependencyDirectivesSourceMinimizer.cpp | ||
HeaderMap.cpp | ||
HeaderSearch.cpp | ||
Lexer.cpp | ||
LiteralSupport.cpp | ||
MacroArgs.cpp | ||
MacroInfo.cpp | ||
ModuleMap.cpp | ||
PPCaching.cpp | ||
PPCallbacks.cpp | ||
PPConditionalDirectiveRecord.cpp | ||
PPDirectives.cpp | ||
PPExpressions.cpp | ||
PPLexerChange.cpp | ||
PPMacroExpansion.cpp | ||
Pragma.cpp | ||
PreprocessingRecord.cpp | ||
Preprocessor.cpp | ||
PreprocessorLexer.cpp | ||
ScratchBuffer.cpp | ||
TokenConcatenation.cpp | ||
TokenLexer.cpp | ||
UnicodeCharSets.h |