================
@@ -330,3 +353,20 @@ DependencyScanningWorkerFilesystem::openFileForRead(const 
Twine &Path) {
     return Result.getError();
   return DepScanFile::create(Result.get());
 }
+
+std::error_code DependencyScanningWorkerFilesystem::setCurrentWorkingDirectory(
+    const Twine &Path) {
+  updateWorkingDirForCacheLookup(Path.str());
+  return ProxyFileSystem::setCurrentWorkingDirectory(Path);
+}
+
+void DependencyScanningWorkerFilesystem::updateWorkingDirForCacheLookup(
+    llvm::ErrorOr<std::string> CWD) {
+  if (CWD && !CWD->empty()) {
+    WorkingDirForCacheLookup = *CWD;
+  } else {
+    // The cache lookup functions will not accept relative paths for safety, so
+    // at least make it absolute from a "root".
+    WorkingDirForCacheLookup = "/";
----------------
akyrtzi wrote:

> For the setCurrentWorkingDirectory() call, I think it'd be reasonable to 
> clear our CWD if the new one is empty or relative, return an error code and 
> assume the VFS doesn't get used in that state. If it does, hitting one of the 
> "is file path absolute" assertions is fair game.

This would be fine for a command-line compiler invocation where you can emit an 
error and then "abort", but this is undesirable in the context of a libclang 
client, like an IDE, where some recovery in the presence of errors is useful; 
for example, clang could still try to create an AST even in the presence of 
such kind of errors in order to support the editor, instead of providing no 
functionality.

https://github.com/llvm/llvm-project/pull/66122
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to