[REPLCompletions] suppress false positive field completions #51502
Conversation
This file contains 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
Field completions can be wrong when `getproperty` and `propertynames` are overloaded for a target object type, since a custom `getproperty` does not necessarily accept field names. This commit simply suppresses field completions in such cases. Fixes the second part of #51499.
aviatesk
force-pushed
the
avi/51499-2
branch
from
46fe545 to
e041dfd
Compare
aviatesk
added a commit
that referenced
this pull request
Sep 29, 2023
The REPL completion engine employs aggressive inference (incorporating
aggressive global binding resolution and aggressive concrete evaluation,
ignoring `:consistent`-cy), enabling completions in scenarios such as:
```julia
julia> d = Dict{Symbol,Any}(:key => Any[Some(r"x")])
julia> d[:key][1].value.<TAB>
compile_options
match_options
pattern
regex
```
While this approach has proven to be quite effective, it has its
limitations, given that aggressive inference was only activated for the
top-level representing an input code. Therefore, it fails to apply to
general cases like:
```julia
julia> getkeyelem(d) = d[:key][1]
julia> getkeyelem(d).<TAB> # no TAB completion
```
This limitation is the underlying cause of the first part of #51499.
To rectify this, the commit implements the following:
1. generalizes aggressive inference to apply to all child frames,
when they are not cached.
2. enables aggressive constant propagation, allowing the propagation of
mutable Consts.
With these changes, now we can get:
```julia
julia> getkeyelem(d). # TAB completes
julia> getkeyelem(d).value.
compile_options
match_options
pattern
regex
```
In conjunction with #51502, this resolves #51499.
This was referenced Sep 29, 2023
aviatesk
added a commit
that referenced
this pull request
Sep 30, 2023
The REPL completion engine employs aggressive inference (incorporating
aggressive global binding resolution and aggressive concrete evaluation,
ignoring `:consistent`-cy), enabling completions in scenarios such as:
```julia
julia> d = Dict{Symbol,Any}(:key => Any[Some(r"x")])
julia> d[:key][1].value.<TAB>
compile_options
match_options
pattern
regex
```
While this approach has proven to be quite effective, it has its
limitations, given that aggressive inference was only activated for the
top-level representing an input code. Therefore, it fails to apply to
general cases like:
```julia
julia> getkeyelem(d) = d[:key][1]
julia> getkeyelem(d).<TAB> # no TAB completion
```
This limitation is the underlying cause of the first part of #51499.
To rectify this, the commit implements the following:
1. generalizes aggressive inference to apply to all child frames,
when they are not cached.
2. enables aggressive constant propagation, allowing the propagation of
mutable Consts.
With these changes, now we can get:
```julia
julia> getkeyelem(d). # TAB completes
julia> getkeyelem(d).value.
compile_options
match_options
pattern
regex
```
In conjunction with #51502, this resolves #51499.
vtjnash
pushed a commit
that referenced
this pull request
Sep 30, 2023
…es (#51503) The REPL completion engine employs aggressive inference (incorporating aggressive global binding resolution and aggressive concrete evaluation, ignoring `:consistent`-cy), enabling completions in scenarios such as: ```julia julia> d = Dict{Symbol,Any}(:key => Any[Some(r"x")]) julia> d[:key][1].value.<TAB> compile_options match_options pattern regex ``` While this approach has proven to be quite effective, it has its limitations, given that aggressive inference was only activated for the top-level representing an input code. Therefore, it fails to apply to general cases like: ```julia julia> getkeyelem(d) = d[:key][1] julia> getkeyelem(d).<TAB> # no TAB completion ``` This limitation is the underlying cause of the first part of #51499. To rectify this, the commit implements the following: 1. generalizes aggressive inference to apply to all child frames, when they are not cached. 2. enables aggressive constant propagation, allowing the propagation of mutable Consts. With these changes, now we can get: ```julia julia> getkeyelem(d). # TAB completes julia> getkeyelem(d).value. compile_options match_options pattern regex ``` In conjunction with #51502, this resolves #51499.
Pangoraw
added a commit
to Pangoraw/FuzzyCompletions.jl
that referenced
this pull request
Oct 7, 2023
aviatesk
pushed a commit
to JunoLab/FuzzyCompletions.jl
that referenced
this pull request
Oct 25, 2023
* Backport several changes from `REPL.REPLCompletions` - JuliaLang/julia#51502 - JuliaLang/julia#51345 * make field_completion_eligible true for 1.6 Base._which was added in JuliaLang/julia@7b19e09 * Update FuzzyCompletions.jl
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Field completions can be wrong when
getpropertyandpropertynamesare overloaded for a target object type, since a customgetpropertydoes not necessarily accept field names. This commit simply suppresses field completions in such cases. Fixes the second part of #51499.