Incorrect non-portable path warning.

[llamasoft]

I ran into this issue while attempting to build Chromium from source. I can confirm that this issue occurs on at least clang versions 7.0.1-8 (installed via apt) and 10.0.0 (from the Chromium build chain). It should be noted that I was doing this build under the Windows Subsystem for Linux running Ubuntu.

Here are some shell commands to create the file and directory structure needed to reproduce the issue:

mkdir -p "Common"
echo '#include "Thread.hpp"' > "Common/MutexLock.hpp"
echo '' > "Common/Thread.hpp"

mkdir -p "Package/common"
echo '#include "Common/MutexLock.hpp"' > "Package/common/Object.hpp"

# This file being in a subdirectory appears to be important.
# When placed elsewhere, the bug does not occur.
mkdir -p "Package/lib"
echo '
#include "common/Object.hpp"
#include "Common/Thread.hpp"
' > "Package/lib/bug.cpp"

# The order of the include directories is also important.
# When reversed (i.e. -I./Package -I.), the error does not occur.
clang++ -I. -I./Package -Werror -Wall ./Package/lib/bug.cpp

The result will be:

./Package/lib/bug.cpp:3:10: error: non-portable path to file '"common/Thread.hpp"'; specified path differs in case from file name on disk [-Werror,-Wnonportable-include-path]
#include "Common/Thread.hpp"
         ^~~~~~~~~~~~~~~~~~~
         "common/Thread.hpp"
1 error generated.

This is absolutely incorrect. The file common/Thread.hpp doesn't even exist, nor was it ever referenced. It seems to be confusing the directory capitalization of ./Package/common and ./Common

It should be noted that the issue seems to have some rather specific criteria for being triggered. For example, the file being built must be at a different folder depth than the other files. Furthermore, the order of the -I flags matters. When reversed, the issue does not occur.

This seems possibly related to bug 32436, but that one appears to involve symlinks whereas this one only involves actual files.

[llamasoft]

I did a bit more digging. The issue only occurs when running on an NTFS partition mounted in case-insensitive mode (the default). However, the drive's case sensitivity shouldn't matter here: the two "common" directories are in different locations and Thread.hpp only exists in one of them.

Here's the output when the command is run with the -E flag:

./Package/lib/bug.cpp:3:10: error: non-portable path to file '"common/Thread.hpp"'; specified path differs in case from file name on disk [-Werror,-Wnonportable-include-path]
#include "Common/Thread.hpp"
         ^~~~~~~~~~~~~~~~~~~
         "common/Thread.hpp"
# 1 "./Package/lib/bug.cpp"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 389 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "./Package/lib/bug.cpp" 2

# 1 "./Package/common/Object.hpp" 1
# 1 "./Common/MutexLock.hpp" 1
# 1 "./common/Thread.hpp" 1
# 2 "./Common/MutexLock.hpp" 2
# 2 "./Package/common/Object.hpp" 2
# 3 "./Package/lib/bug.cpp" 2
# 1 "./Common/Thread.hpp" 1
# 4 "./Package/lib/bug.cpp" 2

1 error generated.

You can see that it's trying to import "Thread.hpp" twice, but using different paths.

[jyknight]

Interesting!

The mistaken warning doesn't occur on linux using a case-insensitive vfat filesystem.

However, the incorrect capitalization of "./common/Thread.hpp" does also occur in that situation.

On both OSes, LLVM has decided to process #include "Thread.hpp" inside Common/MutexLock.hpp as relative to the ./common directory (with incorrect case!). I suspect this is due to having cached the incorrect-case directory-name from an earlier attempt to locate "common/Object.hpp" in "./common/".

On linux, even after opening "common/Thread.hpp" (with the wrong case), it determines the full path with correct case (/<...wherever...>/Common/Thread.hpp) of the opened file descriptor, via the readlink call in "openFileForRead" in llvm/lib/Support/Unix/Path.inc. I wonder if that's not happening on windows.

[jmigual]

Hi, I'm experiencing this issue with clangd on Windows. I get the following warning:

Non-portable path to file '<delaygraph/delayGraph.h>'; specified path differs in case from file name on disk (fix available)clang(-Wnonportable-include-path)

But my file is in delayGraph/delayGraph (notice capital G)

This is the screenshot of the warning in VS Code:

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Marcus T (llamasoft)

I ran into this issue while attempting to build Chromium from source. I can confirm that this issue occurs on at least clang versions 7.0.1-8 (installed via apt) and 10.0.0 (from the Chromium build chain). It should be noted that I was doing this build under the Windows Subsystem for Linux running Ubuntu.

Here are some shell commands to create the file and directory structure needed to reproduce the issue:

mkdir -p "Common"
echo '#include "Thread.hpp"' > "Common/MutexLock.hpp"
echo '' > "Common/Thread.hpp"

mkdir -p "Package/common"
echo '#include "Common/MutexLock.hpp"' > "Package/common/Object.hpp"

# This file being in a subdirectory appears to be important.
# When placed elsewhere, the bug does not occur.
mkdir -p "Package/lib"
echo '
#include "common/Object.hpp"
#include "Common/Thread.hpp"
' > "Package/lib/bug.cpp"

# The order of the include directories is also important.
# When reversed (i.e. -I./Package -I.), the error does not occur.
clang++ -I. -I./Package -Werror -Wall ./Package/lib/bug.cpp

The result will be:

./Package/lib/bug.cpp:3:10: error: non-portable path to file '"common/Thread.hpp"'; specified path differs in case from file name on disk [-Werror,-Wnonportable-include-path]
#include "Common/Thread.hpp"
         ^~~~~~~~~~~~~~~~~~~
         "common/Thread.hpp"
1 error generated.

This is absolutely incorrect. The file common/Thread.hpp doesn't even exist, nor was it ever referenced. It seems to be confusing the directory capitalization of ./Package/common and ./Common

It should be noted that the issue seems to have some rather specific criteria for being triggered. For example, the file being built must be at a different folder depth than the other files. Furthermore, the order of the -I flags matters. When reversed, the issue does not occur.

This seems possibly related to bug 32436, but that one appears to involve symlinks whereas this one only involves actual files.