Show completions from all overloads in LSP #2241
Open
+113
−25
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This comment has been minimized.
This comment has been minimized.
Contributor
|
qq: why are mypy results differing? I would have assumed it stays the same if it's just lsp? |
Contributor
Author
I'm not sure, maybe this was introduced by a minor change introduced outside of LSP changes. I'll investigate it later. |
Contributor
|
There might be non-determinism in this project's results (perhaps a new regression?), cc @stroxler |
Contributor
|
It's almost certainly nondeterminism (the Unknowns are a hint), I'll disable this project |
Resolves facebook#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<usize> for the overload index, distinguishing a matched overload from no match. Co-Authored-By: Claude Opus 4.5 <[email protected]>
fangyi-zhou
force-pushed
the
overload-completion
branch
from
0368fc0 to
dea6b97
Compare
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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