[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