Kristoffer Carlsson

> @KristofferC set it up, i think? Yep, https://github.com/JuliaLang/julia/blob/ba5cafba6a777be24846b1fdd4be4bd20e3551b5/base/errorshow.jl#L616-L619 https://github.com/JuliaLang/julia/blob/ba5cafba6a777be24846b1fdd4be4bd20e3551b5/stdlib/REPL/src/REPL.jl#L1095-L1109

> How does that work with exception stacks? No idea :D (probably the latest printed)

Really cool. Should we already now swap out the `TypeMapEntry` stuff for the `DispatchableMethod` in here? Seems easier and potentially faster?

Should we define some "calling convention" for this serialized IR? So that the function that gets called know how to look up the arguments without having to put them into...

Is the reason for storing the ssastores explicitly due to the fact that some ssavalues not being used (is_used)? Otherwise, they could potentially just be implicit since every codeinfo statement...

FWIW, I think fixing this is quite hard.

This now works if we disable `recycle`: ```jl julia> f() = @interpret 1+1 f (generic function with 1 method) julia> @interpret f() 2 ``` If I add it back (note...

Here is a MWE of an error (with `recycle` disabled): ```jl struct S a::Float64 end f() = @interpret S(1.0) ``` ```jl julia> f() S(1.0) julia> @interpret f() S(0.0) ```

For anyone that would like to debug the nested interpretation and want to keep your sanity. Duplicate JuliaInterpreter into a new package (JuliaInterpreter2) and do something like ``` f() =...

I think there might be confusion with SSAValues from the outer interpreter getting mixed with SSAValues of the inner interpreter. Presumably, we would need some "tagging" system to tag SSAVaulues...