completions: avoid invalidating handle_completion_resolve

[davidbarsky]

(I accidentally pushed this branch to rust-analyzer, not a fork. Sorry about that.)

I noticed that handle_completion_resolve was taking a longer than I expected, especially immediately after a handle_completion on the same completion item. Naively, I'd expect handle_completion_resolve to be largely instant, as we rust-analyzer did most of the required work in handle_completion completion already.

I did some additional digging and realized that—at least, in VS Code—the only differences between the configuration passed to snap.analysis.completions was in the completion_config/forced_resolve_completions_config, specifically, in CompletionFieldsToResolve. The former had resolve_detail/resolve_documentation set to true; the latter set to false.

This set of changes sped up completions on some work-private projects by about ~20% or so.

[Veykril]

I don't understand the logic here. Changing those to true would basically make us not resolve those fields in handle_completion_resolve, meaning we would never populate those fields at all, ever.

That is all fields being set to false is intentional, given in this code path we want to resolve everything.

[davidbarsky]

Oh, I understand what my mistake was. For whatever reason, the additional detail/documentation panel that was populated by the completionItem/resolve response was hidden. That meant I didn't see any difference before/after this change except a speedup in completions times.

Still, I think it's strange that resolving a single completion item can take as much time as solving for the initial set of completions. I'll close this PR in the meantime.