aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Basic/FileManager.cpp
diff options
context:
space:
mode:
authorDuncan P. N. Exon Smith <dexonsmith@apple.com>2021-09-01 15:35:34 -0400
committerDuncan P. N. Exon Smith <dexonsmith@apple.com>2021-09-01 15:55:33 -0400
commit8976a1e111393aab7b4965196364ad734a17f2d5 (patch)
tree9a03a258a4ada895ed7cd12add76b8f57c8f4048 /clang/lib/Basic/FileManager.cpp
parent6b0636ce535efb8649e7cd01ccd03825fd63f8a2 (diff)
downloadllvm-8976a1e111393aab7b4965196364ad734a17f2d5.zip
llvm-8976a1e111393aab7b4965196364ad734a17f2d5.tar.gz
llvm-8976a1e111393aab7b4965196364ad734a17f2d5.tar.bz2
VFS: Document goals of 'use-external-name' and related logic, NFC
Document 'use-external-name' and the various bits of logic that make it work, to avoid others having to repeat the archival work (given that I added getFileRefReturnsCorrectNameForDifferentStatPath to FileManagerTest, seems possible I understood this once before!). - b59cf679e81483cbb3a9252056b7528f4c49586c added 'use-external-name' to RedirectingFileSystem. This causes `stat`s to return the external name for a redirected file instead of the name it was accessed by, leaking it through the VFS. - d066d4c849be06a01c0d17e8dc206913f4e7bfe3 propagated the external name further through clang::FileManager. - 4dc5573acc0d2e7c59d8bac2543eb25cb4b32984, which added clang::FileEntryRef to clang::FileManager, has complicated concession to account for this as well (since refactored a bit). The goal of 'use-external-name' is to enable Clang to report "real" file paths to users (via diagnostics) and to external tools (such as debuggers reading debug info and build systems reading `.d` files). I've added FIXMEs to look at other channels for communicating the external names, since the current implementation adds complexity to FileManager and exposes an inconsistent interface to clients. Besides that, the FileManager logic appears to be kicking in outside of 'use-external-name'. Seems that *some* vfs::FileSystem implementations canonicalize some paths returned by `stat` in *some* cases (the bug isn't fully understood yet). Volodymyr Sapsai is investigating, this at least better documents what *is* understood.
Diffstat (limited to 'clang/lib/Basic/FileManager.cpp')
-rw-r--r--clang/lib/Basic/FileManager.cpp12
1 files changed, 12 insertions, 0 deletions
diff --git a/clang/lib/Basic/FileManager.cpp b/clang/lib/Basic/FileManager.cpp
index 74cd2f2..c4eae6a 100644
--- a/clang/lib/Basic/FileManager.cpp
+++ b/clang/lib/Basic/FileManager.cpp
@@ -276,6 +276,18 @@ FileManager::getFileRef(StringRef Filename, bool openFile, bool CacheFailure) {
} else {
// Name mismatch. We need a redirect. First grab the actual entry we want
// to return.
+ //
+ // This redirection logic intentionally leaks the external name of a
+ // redirected file that uses 'use-external-name' in \a
+ // vfs::RedirectionFileSystem. This allows clang to report the external
+ // name to users (in diagnostics) and to tools that don't have access to
+ // the VFS (in debug info and dependency '.d' files).
+ //
+ // FIXME: This is pretty complicated. It's also inconsistent with how
+ // "real" filesystems behave and confuses parts of clang expect to see the
+ // name-as-accessed on the \a FileEntryRef. Maybe the returned \a
+ // FileEntryRef::getName() could return the accessed name unmodified, but
+ // make the external name available via a separate API.
auto &Redirection =
*SeenFileEntries
.insert({Status.getName(), FileEntryRef::MapValue(UFE, DirInfo)})