Move code_typed and return_types out of inference

[yuyichao]

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_typed I mentioned in that issue #11590 (comment)

IMHO, these methods (including other code_*'s) doesn't really belong to Core.Inference and 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

[vtjnash]

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)

[yuyichao]

Oh, yeah. This is exactly why I felt so strange when I saw #11452 .....

[yuyichao]

Although hopefully this is not blocking the PR. Since this is also the old behavior.

[vtjnash]

no, although it means you could also fix this by doing a one-liner change from call to Main.Base.call here.

[yuyichao]

@vtjnash Will that do it? This is in the Base module and the call should already be Base.call. No?

[vtjnash]

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.

[yuyichao]

@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)

[yuyichao]

@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?

[vtjnash]

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

[JeffBezanson]

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.

[yuyichao]

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.

[mbauman]

Seems like a straightforward fix, and reflection.jl seems like a good home for these methods. Thanks for tackling this, @yuyichao!

[vtjnash]

my main concern is just that this would make these functions unavailable for use from the inference.ji image @carnaval

[yuyichao]

They are currently still in Inference. I was going to move them out in the next step but I could also try something else.

[carnaval]

Fine for me, go ahead.

[tkelman]

Uh, this was freezing during bootstrap on appveyor.