ioeric added a comment.
Some high-level comments :)
================
Comment at: clang-tools-extra/clangd/index/dex/DexIndex.h:45
+ void build(std::shared_ptr<std::vector<const Symbol *>> Symbols,
+ llvm::ArrayRef<std::string> URISchemes);
----------------
URI schemes are property of `Symbols`. We shouldn't need to pass specify the
schemes again. Dex can collect all possible URI schemes when building the index.
I think we could generate proximity paths for index symbols without knowing
about schemes (when building the index). For example, we could `canonicalize`
the URI (as in `FileDistance.cpp`), for example, by converting `test:///x/y/z`
to `/test:/x/y/z`. For a query, we would first convert query proximity paths
to URIs (of all possible schemes), perform the same canonicalization on URIs,
and then use the canonicalized paths to compute proximity.
================
Comment at: clang-tools-extra/clangd/index/dex/DexIndex.h:64
-private:
+ /// For fuzzyFind() Dex retrieves getRetrievalItemsMultiplier() more items
+ /// than requested via Req.MaxCandidateCount in the first stage of filtering.
----------------
Why are values of multipliers interesting to users? Could these be
implementation details in the cpp file?
================
Comment at: clang-tools-extra/clangd/index/dex/Token.h:99
+/// Boost starts with Count and decreases by 1 for each parent directory token.
+std::vector<std::pair<Token, float>>
+generateQueryProximityPaths(llvm::StringRef AbsolutePath,
----------------
Note that `boost != up traversal distance` in most cases. We could return the
distance here and let users decide what the exact boost score is.
================
Comment at: clang-tools-extra/unittests/clangd/DexIndexTests.cpp:33
+std::vector<std::string> URISchemes = {"file"};
+
----------------
Use `unittest` scheme defined in TestFS.cpp
https://reviews.llvm.org/D51481
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
