Move code_typed and return_types out of inference #11600
Conversation
| @@ -3276,44 +3276,6 @@ function replace_getfield!(ast, e::ANY, tupname, vals, sv, i0) | |||
| end | |||
| end | |||
|
|
|||
| function code_typed(f, types::ANY; optimize=true) | |||
| types = to_tuple_type(types) | |||
| code_typed(call, Tuple{isa(f,Type)?Type{f}:typeof(f), types.parameters...}, optimize=optimize) | |||
There was a problem hiding this comment.
It was using the wrong "call" function here. @JeffBezanson is it possible to express the notion of "the call function that would have been visible to the callee" in this function? (cough#11452cough)
There was a problem hiding this comment.
Oh, yeah. This is exactly why I felt so strange when I saw #11452 .....
There was a problem hiding this comment.
Although hopefully this is not blocking the PR. Since this is also the old behavior.
There was a problem hiding this comment.
no, although it means you could also fix this by doing a one-liner change from call to Main.Base.call here.
There was a problem hiding this comment.
@vtjnash Will that do it? This is in the Base module and the call should already be Base.call. No?
There was a problem hiding this comment.
no, and that's the current behavior. This call refers to Core.Inference.call because of the file that it is in, not Main.Base.call.
There was a problem hiding this comment.
@vtjnash Ahh. Maybe that's why it was broken before then. This used to be only defined in Core.Inference with a wrapper in Base. After moving it out of Inference, the call is pointing to the correct function now. (Note that reflection.jl is also included in sysimg.jl)
There was a problem hiding this comment.
@vtjnash Somehow I always thought you what you meant is that the code in this PR is having problem getting the correct call.
So should I do the one-liner (ok maybe two since there's also return_types) and experimenting with moving these out of Inference in another PR?
There was a problem hiding this comment.
I think it's fine to move these out with this PR, I just wanted to point out why this worked (more than just "seems to fix it") and see if @JeffBezanson could recommend any other improvement
There was a problem hiding this comment.
One thing that can be done is to have the macros generate an escaped call symbol, in order to pass the call function from the calling context.
The general problem is a case like methods(call, Tuple{Any, ..., where you obviously can't look at the first argument to see what module call is from.
|
Any more comments? @JeffBezanson maybe? I'll rebase and merge in a day or two if the CI passes again and there's no more comments. |
|
Seems like a straightforward fix, and |
|
my main concern is just that this would make these functions unavailable for use from the inference.ji image @carnaval |
|
They are currently still in |
|
Fine for me, go ahead. |
Move code_typed and return_types out of inference
|
Uh, this was freezing during bootstrap on appveyor. |
I'm still not sure what exactly is the reason for #11590 but this seems to fix it, as well as the error when inspecting
code_typedI mentioned in that issue #11590 (comment)IMHO, these methods (including other
code_*'s) doesn't really belong toCore.Inferenceand can probably be moved into a different file (interactiveutil.jl?). (Leave them here for now since I don't want to change everything at the same time....)Fix #11590
@mbauman