[PATCH] D40548: [clangd] Symbol index interfaces and an in-memory index implementation.

[Eric Liu via Phabricator via cfe-commits]

ioeric added inline comments.


================
Comment at: clangd/index/Index.h:134
+  virtual bool
+  fuzzyFind(Context &Ctx, const FuzzyFindRequest &Req,
+            std::function<void(const Symbol &)> Callback) const = 0;
----------------
malaperle wrote:
> ioeric wrote:
> > malaperle wrote:
> > > I think a more generic std::function would be useful, similar to the indexstore's filter
> > > ```
> > > bool searchSymbols(llvm::function_ref<bool(IndexRecordSymbol, bool &stop)> filter,
> > >                      llvm::function_ref<void(IndexRecordSymbol)> receiver)
> > > ```
> > Do you have an use case in mind which requires different filtering? This could probably be a separate interface. 
> > 
> > I think the behavior of fuzzy finding is well-defined, and how filtering is done is an implementation detail. User-specified filter might make implementation less flexible, especially for large indexes that are not managed in memory. 
> For example
> - Searching by USR
> - By non-qualified name (useful also for Open Workspace Symbol)
> - Most likely other filters, hmm, by Symbol kind, language?
> - No filter, i.e. retrieve *all* symbols. Useful mainly for development and to get index statistics
> 
> There could also be a boolean in the callback return value (or the filter callback) to limit the number of returned values.
> I haven't tried locally but it looks like it would be pretty doable to change the FuzzyFindRequest into a std::function.
> A big disadvantage of having just one method though is that is would be difficult for an implementation to optimize for a specific type of query. For example, if you search by non-qualified name, an implementation could use a mapping of non-qualified-name-to-USR but it would be difficult to know what to do given only the std::function/filter passed by argument.
> In that sense, perhaps it is better to have multiple methods for each use cases. Or perhaps some enum for each kind of query. What do you think?
Adding new interfaces is an option. It should also be easy to extend the existing interface to cover more use cases.

> Searching by USR
We definitely want an interface for this. I can see this being useful for Goto-definition and other features.
> By non-qualified name (useful also for Open Workspace Symbol)
I think `fuzzyFind` can support this, with fuzzy matching optionally turned off if preferred.
> Most likely other filters, hmm, by Symbol kind, language?
Similarly, this could be achieved by extending the find request to include more filters e.g. symbol kind. 
> No filter, i.e. retrieve *all* symbols. Useful mainly for development and to get index statistics
This can be done today by setting an empty fuzzy filter.




Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D40548