ChuanqiXu9 wrote:
> instead of introducing a new concept of `ProjectModulesCache` and requiring
> each `ProjectModules` implementation to know about it and work with it; what
> about introducing a:
>
> ```c++
> class CachingProjectModules : public ProjectModules {
> public:
> CachingProjectModules(GlobalCompilationDatabase &CDB);
> // Implements rest of the operations with a cache overlay.
> ...;
> // Whenever cache is invalid/empty, queries `CDB` for underlying
> `ProjectModules`
> // and updates/builds a cache using it.
> };
> ```
>
> into `ModulesBuilder.cpp` and have an instance of this in
> `ModulesBuilderImpl`? That way we can centralize how the caching will work
> and won't need to maintain multiple implementations that play with it.
>
> As for cache validation, i think it's fine to invalidate based on file
> contents and whenever there's a mismatch we can query `CDB` again.
>
> WDYT?
It sounds good but it has a small problem that:
- Now the ScanningProjectModules are owned by different calls to
`ModulesBuilder::buildPrerequisiteModulesFor`. So we don't need to care about
thread safety in ScanningProjectModules. And if we make it the underlying
ProjectModules, we need to care about the thead safety and then we would have a
centralized scanner. It is not bad but it might be a bigger change.
https://github.com/llvm/llvm-project/pull/125988
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
