clang-cl /showIncludes reports wrong filename for symlinked files

[zmodem]

This can come up in distributed build systems with content-addressed filesystems, where identical files (often empty files) end up hard-linked to the same file.

Consider:

$ touch /tmp/foo.h
$ ln /tmp/foo.h /tmp/bar.h
$ cat > /tmp/a.cc
#include "/tmp/foo.h"
#include "/tmp/bar.h"
void f();
$ clang-cl -c /tmp/a.cc -showIncludes
Note: including file: /tmp/foo.h
Note: including file: /tmp/foo.h

The second include line should refer to bar.h.

This is a problem for systems which rely on the output of /showIncludes to discover all compilation inputs.

Interestingly, the -MD option does not seem to have this problem:

$ clang -MD -c /tmp/a.cc && cat a.d     
a.o: /tmp/a.cc /tmp/foo.h /tmp/bar.h

This all seems related to the discussion in https://reviews.llvm.org/D135220#3862893 about FileManager merging files based on inode.

[llvmbot]

@llvm/issue-subscribers-flang-frontend

[benlangmuir]

I debugged the difference between these:

• We are tracking a separate FileID and FileInfo per include, but only one ContentCache for the file.
• FileInfo::get mutates ContentCache::Filename. This is very similar to the issue with OrigEntry here.
• -MD uses SourceManager::getNonBuiltinFilenameForID which uses ContentCache::Filename
• /showIncludes uses SourceManager::getPresumedLoc which ultimately uses ContentCache->OrigEntry->getName(), which is not mutated since D135220.

It seems like either the filename/OrigEntry stuff should move up into FileInfo or we should be adding a separate ContentCache for the differently named entry instead of sharing one.

[dexonsmith]

IMO, the filename should move up into FileInfo.

[zmodem]

Thanks for investigating!

Is someone looking into moving the filename, or is it a "patches welcome" situation?

[benlangmuir]

Sketch of a fix: https://reviews.llvm.org/D137304. It may take me a little while to get back to this and finish the TODO items.

[atetubou]

@zmodem this issue is for hardlinked file instaed of symlinked file?

[zmodem]

@zmodem this issue is for hardlinked file instaed of symlinked file?

I don't remember the details. In the original bug where we hit this (internal b/256760757) it was hardlinks, but I think symlinks may have the same problem.