bnbarham added inline comments.
================ Comment at: clang/unittests/Serialization/ModuleCacheTest.cpp:125-126 + ASSERT_TRUE(Invocation2); + CompilerInstance Instance2(Instance.getPCHContainerOperations(), + &Instance.getModuleCache()); + Instance2.setDiagnostics(Diags.get()); ---------------- vsapsai wrote: > Haven't rechecked the code more carefully but had an idea is that if we want > to allow InMemoryModuleCache reuse between multiple CompilerInstance, safer > API would be to transfer ModuleCache ownership to the new CompilerInstance > and maybe make all records in the cache purgeable. But that's applicable only > if ModuleCache reuse is important. Every module compilation runs in a separate thread with a separate CompilerInstance (but shared cache). So ownership would have to be transferred back to the original instance once complete. I might be misunderstanding what you mean here though. Another point to note is that eg. Swift doesn't actually create another CompilerInstance, it's just re-used across module loading and `CompilerInstance::loadModule` is called directly. I went with this way in the test as otherwise we'd need to inline most of `ExecuteAction` and have a custom `FrontendAction`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D105328/new/ https://reviews.llvm.org/D105328 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
