The scoring function is fuzzy-match-quality * existing quality score.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
clangd/ClangdUnit.cpp | ||
---|---|---|
377 ↗ | (On Diff #125311) | 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... |
380 ↗ | (On Diff #125311) | Any reason not to use CompletionItemScores here? Maybe copy over some comments? |
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...
clangd/ClangdUnit.cpp | ||
---|---|---|
377 ↗ | (On Diff #125311) | Described this sensitivity. |
380 ↗ | (On Diff #125311) | 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. |
LGTM.
test/clangd/completion-fuzzy.test | ||
---|---|---|
1 ↗ | (On Diff #129622) | nit: any reason not using unittest CodeCompleteTests here? |
Unit test instead of lit test.
test/clangd/completion-fuzzy.test | ||
---|---|---|
1 ↗ | (On Diff #129622) | Whoops, none at all! Done. |