[llvm-bugs] [Bug 26579] New: #include gets wrong file in presence of hardlinks

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26579

            Bug ID: 26579
           Summary: #include gets wrong file in presence of hardlinks
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jyknight at google.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

The following program demonstrates that clang fails to find the proper "current
file's directory" to use for resolving an #include filename, if FileManager has
somehow already learned about another file with the same inode, in a different
directory.

While this reproduction uses simple includes, this is a particularly bad
problem with modules -- where FileManager is informed about many more files
that aren't necessarily even included by the C file being built -- and when you
are compiling on a content-addressable-storage system, where all files with the
same content are always hardlinked.

==== reproduction case ====

mkdir dir1 dir2
echo '#include "other.h"' > dir1/a.h
cp dir1/a.h dir2/a.h

cat >> dir1/other.h <<EOF
#ifdef DIR1
#error included dir1/other.h twice!
#endif
#define DIR1
EOF

echo '' > dir2/other.h

cat >> main.c <<EOF
#include "dir1/a.h"
#include "dir2/a.h"
EOF

## Just to show that the program normally works fine, no error:
clang -E main.c

## Now, replace the copy with a hardlink...
rm dir2/a.h
ln dir1/a.h dir2/a.h

## And it fails with the #error, because the #include "other.h" from
## "dir2/a.h" incorrectly believes that the current file is actually
## "dir1/a.h"!
clang -E main.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160211/9758ab7a/attachment.html>