Open Quuxplusone opened 7 years ago
Bugzilla Link | PR32436 |
Status | NEW |
Importance | P enhancement |
Reported by | Lubos Dolezel (lubos@dolezel.info) |
Reported on | 2017-03-27 11:10:51 -0700 |
Last modified on | 2020-01-11 19:17:34 -0800 |
Version | 9.0 |
Hardware | PC Linux |
CC | eniebler@boost.org, llvm-bugs@lists.llvm.org, nikolaus.wittenstein@gmail.com, rnk@google.com, yan12125@gmail.com |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
Can you provide a reproducer? I suspect this is some bad interaction between frameworks / modules / stuff that Apple uses and -Wnonportable-include-path, which probably assumes normal include path search.
I've figured it out, it's a little more complicated. Clang seems to check if
the included file is also available when a different case is used for parts of
the path. If that happens to be the case, it reports a warning.
Reproducer:
mkdir testdir
touch testdir/header.h
ln -s . testdir/TestDir
echo "#include <TestDir/header.h>" | clang-4.0 -c -xc -I. -I./testdir -
Will produce this output:
<stdin>:1:10: warning: non-portable path to file '<testdir/header.h>';
specified path differs in case from file name on disk [-Wnonportable-include-
path]
#include <TestDir/header.h>
^~~~~~~~~~~~~~~~~~
<testdir/header.h>
1 warning generated.
Got it. This seems like a bad false positive, since testdir/header.h doesn't actually exist, and #include <testdir/header.h>
would fail.
Thanks for the test case. Hopefully Taewook has some time to look into it.
Thank you for the report. I cced Eric, who is the original author of this code.
I tried repro on my linux machine with more recent clang (about 2 weeks old),
but it throws a file not found error:
echo "#include <TestDir/header.h>" | ~/llvms/fb-master/install-
release/bin/clang -c -xc -I. -I../testdir -
<stdin>:1:10: fatal error: 'TestDir/header.h' file not found
#include <TestDir/header.h>
^~~~~~~~~~~~~~~~~~
1 error generated.
Did I miss anything? Thanks!
It's -I./testdir, not -I../testdir
Oops, sorry my bad. Thanks!
Is it only a problem if you have created a symbolic link to the same directory with the same name only differing in case?
If we knew the file in question lives on a case-sensitive file system, we could just not issue the warning. Not sure if we can get that information, though.
I don't know if this scenario is the only one that causes the problem, but I wonder how it makes the check?
I'm not directly using the lower-case path anywhere in my example and if it would check the path directory-by-directory, it would see it's perfectly correct.
I just ran into this same issue in Clang 9. It looks like this warning will
fire any time that the path of the symlink's target is the same (except for
case) as the include path. Another repro without folders at all:
touch foo.h
ln -s foo.h Foo.h
echo '#include "Foo.h"' | clang -c -xc -
Output:
<stdin>:1:10: warning: non-portable path to file '"foo.h"'; specified path
differs in case from file name on disk [-Wnonportable-include-path]
#include "Foo.h"
^~~~~~~
"foo.h"
1 warning generated.
It looks like source for this warning is somewhere in here:
https://github.com/llvm-mirror/clang/blob/c6e4e7210cd1f80a0492f6bf1dc1f717a1cf0351/lib/Lex/PPDirectives.cpp#L2096.