Bogus non-portable path warnings

[Quuxplusone]

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

Clang 4.0 reports bogus warnings about non-portable paths on Linux (where non-
portable paths probably can't even exist).

Example:
/home/lubos/Projects/darling/src/external/corefoundation/CoreFoundation/CFRunLoop.h:33:10:
warning: non-portable path to file '<corefoundation/CFDate.h>'; specified path
differs in case from file name on disk [-Wnonportable-include-path]
#include <CoreFoundation/CFDate.h>
         ^~~~~~~~~~~~~~~~~~~~~~~~~
         <corefoundation/CFDate.h>

This happens when building source code on Linux with '-target x86_64-apple-
darwin11' (crosscompiling).

As is obvious from the example above, it seems clang internally makes parts of
the include path lower case, only to later complain about it.

[Quuxplusone]

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.

[Quuxplusone]

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.

[Quuxplusone]

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.

[Quuxplusone]

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!

[Quuxplusone]

It's -I./testdir, not -I../testdir

[Quuxplusone]

Oops, sorry my bad. Thanks!

[Quuxplusone]

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.

[Quuxplusone]

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.

[Quuxplusone]

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.