The scoring function is fuzzy-match-quality * existing quality score.
Details
Diff Detail
- Repository
- rCTE Clang Tools Extra
- Build Status
Buildable 12713 Build 12713: arc lint + arc unit
Event Timeline
| clangd/ClangdUnit.cpp | ||
|---|---|---|
| 377 | 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 | 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 | Described this sensitivity. | |
| 380 | 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 | ||
|---|---|---|
| 2 | nit: any reason not using unittest CodeCompleteTests here? | |
Unit test instead of lit test.
| test/clangd/completion-fuzzy.test | ||
|---|---|---|
| 2 | Whoops, none at all! Done. | |
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...