jansvoboda11 wrote:
To clarify, I'm not concerned about the general issue of `FileManager` and VFS
working directory mismatch. What I'm wary of is that this patch changes
`FileSystemOptions` after creating and (potentially) using `FileManager` for a
while. It uses relative paths as cache keys:
```c++
auto FileMgr = llvm::makeIntrusiveRefCnt<FileManager>(FileSystemOptions{},
FinalFS);
FileMgr->getOptionalFileRef("tu.c"); // caches "<VFS-CWD>/tu.c"
FileMgr->getFileSystemOpts() = ScanInstance.getFileSystemOpts(); // with
WorkingDir = "<CLI-CWD>"
FileMgr->getOptionalFileRef("tu.c"); // returns cached "<VFS-CWD>/tu.c" instead
of looking up "<CLI-CWD>/tu.c"
```
> The driver calls `VFS->setCurrentWorkingDirectory` using the value of
> `-working-directory`. So in general relative paths will be resolved
> consistently with `-working-directory` if they're seen before configuring the
> `FileManager`.
Right, the driver uses VFS directly instead of going through `FileManager`, so
caching isn't a concern. Driver's usage of `DiagnosticsEngine` (configured with
`FileManager`) probably won't cause any actual file lookups. We're also passing
`FileManager` to `tooling::ToolInvocation`, but that doesn't do much besides
invoking the driver. Any of this might change, though.
We could prevent this by throwing away the provisional `FileManager` and its
clients after dealing with the driver command line and create new ones before
scanning.
https://github.com/llvm/llvm-project/pull/84525
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
