This fixes an issue where the toolchain discovery doesn't respect the
VFS's current working directory, specifically clangd not respecting a
relative /winsysroot.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Re test: Maybe some combination of -ivfsoverlay (as a /clang: flag I suppose) and /winsysroot can be used to test this?
(aside: Do you know if the sysroot vs clangd stuff works on non-win? I happened to see https://bugs.llvm.org/show_bug.cgi?id=27909)
In Linux.cpp I only see uses of VFS, no uses of llvm::sys::fs so I think it should work there. And using clangd on vscode on Linux, it works with --sysroot.
Looks like -ivfsoverlay doesn't take effect in the driver. And -working-directory also changes the program's working directory since there's no vfs in the driver so it uses the actual fs.
lgtm
I think we also do some registry searching, which is not virtualized. I guess those are all absolute references and paths, so if you use clangd on the same machine, it should just work.
It occurs to me that this code is suddenly much more unit testable now that it uses a VFS, but it doesn't seem reasonable to request unit tests.
clang/lib/Driver/ToolChains/MSVC.cpp | ||
---|---|---|
361 | This function already takes TC, which has TC.getVFS, so I think you can skip the extra parameter. |
We don't use a VFS for registry searching because we just take the value given by the registry and pass it on, rather than checking for the existence of specific files/directories. But yeah they're probably all absolute paths so it shouldn't matter in those cases.
This function already takes TC, which has TC.getVFS, so I think you can skip the extra parameter.