Stopgap fix for finding module for a file mapped in the VFS
authorBen Langmuir <blangmuir@apple.com>
Fri, 23 May 2014 18:15:47 +0000 (18:15 +0000)
committerBen Langmuir <blangmuir@apple.com>
Fri, 23 May 2014 18:15:47 +0000 (18:15 +0000)
commit5de00f3b56805c7e980f049ceb3f166f8c69cec0
tree1ae1c0ee9e452f85526ef0334ecd4b115b315c0b
parent8651081bbe4b8e798a06b4e5b429098b58a1435d
Stopgap fix for finding module for a file mapped in the VFS

If we lookup a path using its 'real' path first, we need to ensure that
when we run header search we still use the VFS-mapped path or we will
not be able to find the corresponding module for the header.

The real problem is that we tie the name of a file to its underlying
FileEntry, which is uniqued by inode, so we only ever get the first name
it is looked up by. This doesn't work with modules, which rely on a
specific file system structure.  I'm hoping to have time to write up a
proposal for fixing this more permanently soon, but as a stopgap this
patch updates the name of the file's directory if it comes from a VFS
mapping.

llvm-svn: 209534
12 files changed:
clang/include/clang/Basic/FileSystemStatCache.h
clang/include/clang/Basic/VirtualFileSystem.h
clang/lib/Basic/FileManager.cpp
clang/lib/Basic/FileSystemStatCache.cpp
clang/lib/Basic/VirtualFileSystem.cpp
clang/test/VFS/Inputs/actual_module.map
clang/test/VFS/Inputs/import_some_frame.h [new file with mode: 0644]
clang/test/VFS/Inputs/public_header.h
clang/test/VFS/Inputs/public_header2.h [new file with mode: 0644]
clang/test/VFS/Inputs/some_frame_module.map [new file with mode: 0644]
clang/test/VFS/Inputs/vfsoverlay.yaml
clang/test/VFS/real-path-found-first.m [new file with mode: 0644]