[PATCH] D40780: [clangd] Incorporate fuzzy-match into result rankings.

[Sam McCall via Phabricator via cfe-commits]

sammccall marked 2 inline comments as done.
sammccall added a comment.

Tested in this file:

  #include <memory>
  #include <unordered_map>
  #include <vector>
  int main() { std::^ }

Before this change:

  u -> __has_argument_type, __has_first_argument_type...
  un -> __has_argument_type, __has_first_argument_type...
  u_p -> __has_argument_type, __has_first_argument_type...
  um -> uintmax_t, unordered_map, unordered_multimap...

After this change

  u -> u16streampos, u16string, u32streampos...
  un -> unary_function, unary_negate, uncaught_exception...
  u_p -> unique_ptr, undeclare_no_pointers, __has_argument_type...
  um -> unordered_map, unordered_multimap, __has_argument_type...



================
Comment at: clangd/ClangdUnit.cpp:377
+      : Result(&Result), SymbolScore(score(Result)), FilterScore(FilterScore),
+        Score(FilterScore * SymbolScore) {}
 
----------------
ioeric wrote:
> It might worth mentioning how well `FilterScore * SymbolScore` performs. I think it could be affected by the distribution of the filtering score and symbol scores. We might want to do some tweaks on the numbers depending on the distributions...
Described this sensitivity.


================
Comment at: clangd/ClangdUnit.cpp:380
   CodeCompletionResult *Result;
-  float Score; // 0 to 1, higher is better.
+  float SymbolScore; // higher is better
+  float FilterScore; // 0 to 1, higher is better.
----------------
ioeric wrote:
> Any reason not to use `CompletionItemScores` here? Maybe copy over some comments?
Done. My feeling was that CompletionItemScores was an API and we shouldn't couple our internal layout to it. But it's convenient now and may remain so, we can change it later.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D40780