Use type inference to determine the call signature for method completion. #11679

dhoegh · 2015-06-12T12:49:40Z

This pull implement method completion using type inference to determine the input types for a function call, Second case in #6338. This means the method completion suggestion removes the methods not appropriate for the function call, see:

julia> dot([1],<tab>
dot(x::AbstractArray{T,1}, y::AbstractArray{T,1}) at linalg/generic.jl:280
julia> dot(max(1,1),<tab>
dot(x::Number, y::Number) at linalg/generic.jl:279

~~The only thing I do not like about the implementation, is the need for eval an expression of the arguments into an anonymous function, see line:~~

julia/base/REPLCompletions.jl

Line 273 in 1940b8f

afunc=eval(Expr(:->, Expr(:tuple, key_s...), ex_org.args[i]))

. I do only let type inference work its magic on the anonymous function so the anonymous function is never called, so it might be ok? This might not be necessary if I could create the LambdaStaticData manually for the anonymous function, anyone know how this could be done?
It only analyse function arguments that is a call or is lowered to a call. Hence this do not work when the arguments is an expression. Example the time macro return an expression. I have also added this as a test case in https://github.com/dhoegh/julia/blob/603d16c7742fed2b10106402ec7284cf0e7c1f6e/test/replcompletions.jl#L292.
cc @blakejohnson could you review this, you reviewed similar additions in #9676?

~~Further work on this pull includes~~

~~Make tests~~

tkelman · 2015-06-12T23:10:29Z

base/REPLCompletions.jl

@@ -203,35 +203,77 @@ function find_start_brace(s::AbstractString)
 end

 # Returns the value in a expression if sym is defined in current namespace fn.
+# The vars argument is a dictionary that contains all variables in the ex_org 


trailing whitespace

dhoegh · 2015-06-13T13:05:20Z

@tkelman thank you for the reminder, I have pushed a new version with fixed whitespaces and added test cases.

blakejohnson · 2015-06-13T13:22:30Z

I'll try to take a look at this later this weekend.

dhoegh · 2015-06-13T13:37:40Z

Thank you @blakejohnson, the Travis/Appveyor failures are unrelated.

dhoegh · 2015-06-14T10:28:33Z

@blakejohnson, the code is not versatile enough to handle all cases, so hold off reviewing this.
I need to figure out how to use the inference in a more generic way. I would like to tell the inference to assume that the global variables in the function do not change type.

dhoegh · 2015-10-13T17:30:45Z

I finally got around to rebase and solve this PR in a better way. @blakejohnson Could you review this?

dhoegh · 2015-10-24T15:52:15Z

Bump, anyone willing to review.

blakejohnson · 2015-10-25T02:09:49Z

Sorry, if no one gets to it before me, I'll try to have a look early this week.

dhoegh · 2015-11-07T14:19:35Z

Bump.

blakejohnson · 2015-11-08T02:07:36Z

So, my reading of this change is that it appears correct. I always have some trouble reading code that does expression parsing, though, because it is never particularly clear what you are extracting in statements like ex.args[2].

How do people feel about REPL completion behavior depending on type inference? There has previously been resistance to making program behavior depend on inference. This seems like a different category, though, since the programs you write aren't changed, but only the help you receive while writing them.

blakejohnson · 2015-11-08T02:08:24Z

base/REPLCompletions.jl

@@ -222,14 +222,61 @@ get_value(sym::Symbol, fn) = isdefined(fn, sym) ? (fn.(sym), true) : (nothing, f
 get_value(sym::QuoteNode, fn) = isdefined(fn, sym.value) ? (fn.(sym.value), true) : (nothing, false)
 get_value(sym, fn) = sym, true

+# Return the value of a getfield call expression
+function get_value_getfield(ex::Expr, fn)
+    val, found = get_value_getfield(ex.args[2],fn)


can we help the reader with a comment about what is contained in ex.args[2] and ex.args[3]?

blakejohnson · 2015-11-08T02:09:57Z

Thank you, @dhoegh, for including some thorough tests with this change.

tkelman · 2015-11-08T07:09:46Z

Since this is interactive, the inference issue seems less critical here. Though hypothetically could user programs hook into this and try to use it for other purposes? Maybe not worth worrying about.

dhoegh · 2015-11-08T12:37:10Z

So, my reading of this change is that it appears correct. I always have some trouble reading code that does expression parsing, though, because it is never particularly clear what you are extracting in statements like ex.args[2].

I have added further comments, to try to clarify what is happening.

yuyichao · 2015-11-08T13:12:00Z

Though hypothetically could user programs hook into this and try to use it for other purposes?

It can always call type inference directly, e.g. code_typed, return_types etc, so there's nothing to worry about type-inference dependence there.

tkelman · 2015-11-08T13:38:05Z

Ah yeah, duh. Nevermind then.

This looks okay to me, shall we merge?

blakejohnson · 2015-11-08T13:49:08Z

Yes, I think this is good to merge.
On Sun, Nov 8, 2015 at 8:38 AM Tony Kelman [email protected] wrote:

Ah yeah, duh. Nevermind then.

This looks okay to me, shall we merge?

—
Reply to this email directly or view it on GitHub
#11679 (comment).

…ove non matching methods. Add test for the new functionality, fix JuliaLang#6338.

dhoegh · 2015-11-08T14:26:31Z

I have just squashed the commits, so this should be good to merge.

Use type inference to determine the call signature for method completion.

KristofferC · 2015-11-08T18:32:45Z

Cool, this is a nice thing to have.

dhoegh · 2015-11-08T19:31:30Z

Thank you, @blakejohnson, for the review and merge.

…ove non matching methods. Add test for the new functionality, fix #6338. (cherry picked from commit f8196cc) ref #11679

tkelman added the REPL Julia's REPL (Read Eval Print Loop) label Jun 12, 2015

tkelman reviewed Jun 12, 2015
View reviewed changes

dhoegh force-pushed the method_comp_inference branch from 1940b8f to 53bad69 Compare June 13, 2015 13:03

dhoegh force-pushed the method_comp_inference branch 4 times, most recently from 6b13082 to 603d16c Compare October 13, 2015 17:19

blakejohnson reviewed Nov 8, 2015
View reviewed changes

dhoegh force-pushed the method_comp_inference branch from 9cf4959 to 9e41f5e Compare November 8, 2015 12:34

Method completion using inference to determine the input types to rem…

f8196cc

…ove non matching methods. Add test for the new functionality, fix JuliaLang#6338.

dhoegh force-pushed the method_comp_inference branch from 9e41f5e to f8196cc Compare November 8, 2015 14:25

blakejohnson added a commit that referenced this pull request Nov 8, 2015

Merge pull request #11679 from dhoegh/method_comp_inference

e9af3f6

Use type inference to determine the call signature for method completion.

blakejohnson merged commit e9af3f6 into JuliaLang:master Nov 8, 2015

ivarne added the backport pending 0.4 label Nov 8, 2015

tkelman pushed a commit that referenced this pull request Nov 29, 2015

Method completion using inference to determine the input types to rem…

931cfbe

…ove non matching methods. Add test for the new functionality, fix #6338. (cherry picked from commit f8196cc) ref #11679

tkelman removed the backport pending 0.4 label Dec 7, 2015

dhoegh mentioned this pull request Mar 28, 2016

Use inference in dot completion FIX #10091. #15652

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use type inference to determine the call signature for method completion. #11679

Use type inference to determine the call signature for method completion. #11679

dhoegh commented Jun 12, 2015

tkelman Jun 12, 2015

dhoegh commented Jun 13, 2015

blakejohnson commented Jun 13, 2015

dhoegh commented Jun 13, 2015

dhoegh commented Jun 14, 2015

dhoegh commented Oct 13, 2015

dhoegh commented Oct 24, 2015

blakejohnson commented Oct 25, 2015

dhoegh commented Nov 7, 2015

blakejohnson commented Nov 8, 2015

blakejohnson Nov 8, 2015

blakejohnson commented Nov 8, 2015

tkelman commented Nov 8, 2015

dhoegh commented Nov 8, 2015

yuyichao commented Nov 8, 2015

tkelman commented Nov 8, 2015

blakejohnson commented Nov 8, 2015

dhoegh commented Nov 8, 2015

KristofferC commented Nov 8, 2015

dhoegh commented Nov 8, 2015

Use type inference to determine the call signature for method completion. #11679

Use type inference to determine the call signature for method completion. #11679

Conversation

dhoegh commented Jun 12, 2015

tkelman Jun 12, 2015

Choose a reason for hiding this comment

dhoegh commented Jun 13, 2015

blakejohnson commented Jun 13, 2015

dhoegh commented Jun 13, 2015

dhoegh commented Jun 14, 2015

dhoegh commented Oct 13, 2015

dhoegh commented Oct 24, 2015

blakejohnson commented Oct 25, 2015

dhoegh commented Nov 7, 2015

blakejohnson commented Nov 8, 2015

blakejohnson Nov 8, 2015

Choose a reason for hiding this comment

blakejohnson commented Nov 8, 2015

tkelman commented Nov 8, 2015

dhoegh commented Nov 8, 2015

yuyichao commented Nov 8, 2015

tkelman commented Nov 8, 2015

blakejohnson commented Nov 8, 2015

dhoegh commented Nov 8, 2015

KristofferC commented Nov 8, 2015

dhoegh commented Nov 8, 2015