10:38 <kares[m]> looking into the final piece of not clearing $! ... seems to get ugly quick as the scope changes

10:38 <kares[m]> got it working but I am not sure if its the right way or whether everything was taking care of

10:39 <kares[m]> will get you guys to review a draft PR

11:31 <kares[m]> https://github.com/jruby/jruby/pull/6056

11:54 <kares[m]> so now I am a bit confused why the interpreter is failing trying to read a (temp) local variable ...

14:50 <enebo[m]> kares: seems likely somehow that variable get is happening on wrong interp context

14:51 <enebo[m]> not really sure why...I will have to study what changed here....also this was not passing before so how did this error manifest before?

14:53 <kares[m]> only tried to add an instruction to restore $! ... where I needed to cross a single IRBuilder boundary

14:53 <kares[m]> before the change there's no error but $! leaks (is not nil when it should be)

14:54 <kares[m]> the attempted fix resolved it for my script, but went that piece of code is "inside" the spec it throws AIOoBE

14:57 <enebo[m]> ah yeah this won't work

14:57 <enebo[m]> you are asking for a temp from the parent method which the current context will not have

14:58 <kares[m]> thought it might be messy to cross the boundary

14:59 <kares[m]> not even sure if the attempted fix is the right direction, wdyt?

14:59 <enebo[m]> yeah internally in JIT or in interp temps are either java locals or an array of temps in the current interp method

15:00 <enebo[m]> so this patch added a case for if we did not know the restore variable to ask it's parent for it

15:02 <enebo[m]> I think the scenario you are trying to fix is we are in a soft scope (e.g. closure) and something wants $! at that point but it is unset. Is that right?

15:05 <enebo[m]> If I described what you were trying to do I think one other problem is that $! is a down stack value and the parent would only restore an older value (which may be right or not in this case)

15:10 <enebo[m]> I believe one path to solving this is that activeRescueBlock is not empty in all cases where we encounter non-local returns (or potential non-local because at build time this might not be one [e.g. lambda]).

15:22 <kares[m]> yes in a closure that is being passed to another scope (method) - the closure does a return

15:22 <kares[m]> (an early return happens in the original scope)

15:23 <kares[m]> and the important thing is this is happening from within a rescue

15:25 <kares[m]> so `$!` should be restored. haven't looked how MRI handles these but I guess it will be a different codebase compared to JRuby's IR

15:34 <kares[m]> I think I get what you mean - there's an internal ensure generated that we could tackle

15:52 <kares[m]> or not

16:02 <kares[m]> all the alternatives I could come up with aren't feeling right

16:05 <kares[m]> activeRescueBlock won't be empty at the scope where the closure gets defined

16:05 <kares[m]> but than I call another method which yields and thus the non-local return executes

16:05 <kares[m]> at that point there's no info that I should have restored $! (due coming from a rescue) down the stack ...

16:12 <enebo[m]> we need to push $! at all possible rescue levels as it comes down I think

16:14 <enebo[m]> This arguably is the most complicated part of IR Building

16:14 <enebo[m]> In part because we duplicate a lot of code

16:32 <lopex> https://www.youtube.com/watch?v=9wvEwPLcLcA

17:13 <kares[m]> enebo: get that and it should be handled for most cases except this specific non-local return

17:13 <kares[m]> seems to me like there is no easy way around this, but I am fine to be proven wrong eventually ;)

18:25 <enebo[m]> kares: I am just speculating as well.

19:24 <headius[m]> Yo