[PATCH] D18849: [modules] Avoid module relocation error when building modules from VFS

[Bruno Cardoso Lopes via cfe-commits]

bruno added a comment.

Hi Ben,


================
Comment at: lib/Basic/FileManager.cpp:221-223
@@ -220,2 +220,5 @@
   // See if there is already an entry in the map.
+  // FIXME: Note that when first requested, the returned file name equals to the
+  // requested path. This is not true when returning a cached result. This is
+  // inconsistent and might lead to clients making the wrong assumptions.
   if (NamedFileEnt.second)
----------------
benlangmuir wrote:
> The first time we lookup a file, we will return whatever name comes back from the VFS, which may or may not be the requested path.  If this is a real file system, it will be the requested path.  If it is a redirecting file system and "use-external-names" is true (which it is by default), then the VFS will return the external contents path, which is generally not the same as the requested path.
The behaviour I'm seeing for VFS is a bit different: If it is a redirecting file system and "use-external-names" is true, then the FileManager returns the requested file path. Sub-sequential cached queries return the "use-external-names" / real-path instead. This is the rationale why I'm trying to thread the FileName instead of the FileEntry. Am I missing something?

================
Comment at: lib/Lex/HeaderSearch.cpp:493
@@ -492,3 +492,3 @@
     // Find the framework in which this header occurs.
-    StringRef FrameworkPath = FE->getDir()->getName();
+    StringRef FrameworkPath = llvm::sys::path::parent_path(FrameworkName);
     bool FoundFramework = false;
----------------
benlangmuir wrote:
> What does this change do?  FE->getDir()->getName() will be the virtual path if there is VFS, which is usually the one you want to operate on.
You're right! I assumed FE->getDir()->getName() would give me the real path directory for the file in question, but I double checked here and that doesn't happen.


http://reviews.llvm.org/D18849