aganea wrote:
> > Not sure @jansvoboda11 perhaps if we want to cherry pick
> > [b768a8c](https://github.com/llvm/llvm-project/commit/b768a8c1db85b9e84fd8b356570a3a8fbe37acf6)
> > on `release/18.x`? Or should we land just a simple PR with just the
> > function change above?
>
> I can try pulling
> [b768a8c](https://github.com/llvm/llvm-project/commit/b768a8c1db85b9e84fd8b356570a3a8fbe37acf6)
> into the release branch.
Sorry I've been misleading, pushing b768a8c on 18.x doesn't fix the issue. The
problem is around the directory queries and the function in b768a8c returns
`false` for that case (thus no caching of errors).
Running with:
```
static bool shouldCacheStatFailures(StringRef Filename) {
StringRef Ext = llvm::sys::path::extension(Filename);
if (Ext.empty())
return false; // This may be the module cache directory.
return true;
}
```
Takes 4 min 8 sec.
Then running with:
```
static bool shouldCacheStatFailures(StringRef Filename) {
return true;
}
```
Takes 1 min 47 sec.
I think something more involved would be needed here. @jansvoboda11 in which
case we don't want to consider the file system immutable during the execution
of clang-scan-deps?
https://github.com/llvm/llvm-project/pull/88152
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
