[PATCH] D54269: Introduce shard storage to auto-index.

Kadir Cetinkaya via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Nov 13 02:29:34 PST 2018


kadircet added inline comments.


================
Comment at: clangd/index/Background.h:39
+  retrieveShard(llvm::StringRef ShardIdentifier, FileDigest Hash) const = 0;
+  virtual bool initialize(llvm::StringRef Directory) = 0;
+};
----------------
kadircet wrote:
> sammccall wrote:
> > kadircet wrote:
> > > sammccall wrote:
> > > > Why not use the constructor? what does "directory" mean in the general case?
> > > Directory refers to the one specified in CompilationDatabase(which is usually the build directory?), sorry for the inconvenience.
> > > I wasn't sure about where we plan to instantiate BackgroundIndex. If you plan to do that initialization at a point in which we already know the build directory we can move that to constructor, especially only to the constructor of DiskBackedIndexStorage.
> > tooling::CompileCommand::WorkingDirectory? That doesn't seem especially relevant here.
> > Or the directory that the CDB was discovered in?
> > 
> > Yes, this seems to be only relevant to DiskBackedIndexStorage
> I suppose you meant `tooling::CompileCommand::Directory` rather than `WorkingDirectory` ? That is the one I was talking about, why do you think it is irrelevant ?
Changed logic to use Directory passed to enqueueAll or enqueue, which I assume is the directory that the compilation database lives. And I assumed we will have at most one compilation database per directory.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D54269





More information about the cfe-commits mailing list