[clang] [clang][deps] Fix dependency scanning with -working-directory (PR #84525)

[Jan Svoboda via cfe-commits]

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