Show completions from all overloads in LSP

[fangyi-zhou]

Summary

Resolves #1122

Previously, the LSP code completion for overload only shows the
closest match. This commit shows all possible overloads at the beginning
of code completion, and then switches to the closest match afterwards.

Ideally we want to only show compatible overloads, but doing so would
require re-evaluating overload compatibility with the existing
parameters. If we want to do this, we can filter away incompatible
overloads when we trace the overload traces (I'm not too sure about this).

---

LLM provided summary:

When no arguments have been provided yet, show keyword argument
completions from all overloads. When arguments have been provided,
narrow to the closest matching overload. This is a compromise:
ideally we would show params from all overloads that are compatible
with the arguments so far, but the infrastructure only tracks a
single closest overload, not all compatible ones. Filtering by
compatibility would require either extending OverloadedCallee to
track all matching overloads or re-checking type compatibility in
the completion code.

Also changes get_callables_from_call to return Option for the
overload index, distinguishing a matched overload from no match.

Test Plan

python test.py

[migeed-z]

qq: why are mypy results differing? I would have assumed it stays the same if it's just lsp?

[fangyi-zhou]

qq: why are mypy results differing? I would have assumed it stays the same if it's just lsp?

I'm not sure, maybe this was introduced by a minor change introduced outside of LSP changes. I'll investigate it later.

[yangdanny97]

There might be non-determinism in this project's results (perhaps a new regression?), cc @stroxler

[stroxler]

It's almost certainly nondeterminism (the Unknowns are a hint), I'll disable this project

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[kinto0]

thanks for the contribution! this doesn't seem to solve the problem exactly:

• it only works for kwarg completions
• it stops working after an argument is provided

I wonder if instead we should change get_callables_from_call to return a list of compatible overloads. then, we can reuse this functionality everywhere and pick the first compatible one if we only support 1 choice.

[fangyi-zhou]

Thanks for the review @kinto0 , could you elaborate on this?

it only works for kwarg completions

Do we have any other test cases at the moment for other completions? I probably have missed them.

[kinto0]

if only works for kwarg completions

logic was only added in the add_kwargs_completions function. instead, we should make this fix generalizable across everything (see details below)

it stops working after an argument is provided

// When args have been provided that narrow down the overload, use only
            // the closest matching overload.

I wonder if instead we should change get_callables_from_call to return a list of compatible overloads

right now, add_kwargs_completions calls get_callables_from_call and binds the result to (callables, chosen_overload_index, active_argument, _). if we can also return compatible_overloads here, we can implement this issue for every lsp request, not just kwarg completions. namely, signature help (screenshot in original issue).

Do we have any other test cases at the moment for other completions?

biggest one is signature help (technically not completions), but other ones could be the custom ones like dictionary key completions.