type inference runtime correctness (oldworld)

[vtjnash]

This starts to implement[s] the runtime structures to track type-inference correctness of our statically computed type inference information. It handles ensuring that old (on stack) code won't see mutations to the method tables. Next step will be to [It now] tracks this information more carefully through inference to build and store all of the edges for invalidation to ensure that evaluating new code only sees the newest code.

TODO:

• docs
• get inference running in the correct world
• teach inlineable to call inference for sv.world
• correct handling of optimize=false flag to code_typed
• review code for other critical TODOs
• get staged functions running in the correct world
• compute incremental precompile edges
• scrub documentation. emphasize difference between methods and bindings, move @generated function example
• get inference finish to add the backedge to the right MethodInstance even while resolving cycles
• add default values of the extra arguments to _methods_by_ftype
• investigate how to handle serialize/deserialize
• incrementally forward deserialize the backedges
• NEWs entry
• change cfunction to capture the current world

Later followup work:

• look for optimizations
• dead world pruning
• try to do some inference of unspecialized (esp. during compile-all)
• make "rpc server" example better
• devdocs quickly summarizing how/when the world counter is updated, how min/max ages are updated, and how to temporarily run in different worlds, and the meaning of backedge.

fix #265

[tkelman]

?

[tkelman]

when this is ready for a pkgeval run, let me know - should definitely evaluate the scale of what this is going to break

[JeffBezanson]

Seems like it would catch more cases to put this in abstract_eval instead?

[vtjnash]

Yes, although that would miss the specific case I cared about (turning singleton arguments into Const values).

[JeffBezanson]

I see. In that case it would make more sense to do the transformation at the point where the arguments are received. VarState is wrapper-like, so it's confusing if it changes the thing you're wrapping in addition to wrapping it.

[maleadt]

Did inlining semantics change with this PR? For example:

@noinline child() = return nothing
parent() = child()
@code_llvm parent()

on f27c6f3:

define void @julia_parent_60601() #0 {
top:
  call void @julia_child_60602() #0
  ret void
}

on master (44d7677):

define void @julia_parent_61546() #0 {
top:
  ret void
}

Expected?

[tkelman]

devdocs that explain what a backedge is / means would be good to add before too long