Works in 1.7, does not work in 9k HEAD.

A workaround for you until we fix this: use "break" or "next" instead of "return". Break returns from the method receiving the block (bar) and next returns from the block itself (allowing the lambda to finish normally).

I would guess we're not being strict enough about non-local returns that pass through a containing lambda.

Output on 9k:

[] ~/projects/jruby $ jruby return_test.rb 
Run options: --seed 52562

# Running:

F

Finished in 0.029812s, 33.5440 runs/s, 33.5440 assertions/s.

  1) Failure:
LambdaTest#test_return_with_lambda [return_test.rb:9]:
Expected: "foo"
  Actual: [1]

1 runs, 1 assertions, 1 failures, 0 errors, 0 skips

The problem is actually that the lambda (->) is capturing the return. As a result, each's return value is returned from the bar method.

It passes on MRI and JRuby 1.7 because the assert never fires. The return bubbles all the way out of the test method, as it should.

Simplest repro I can come up with:

def foo
  ->{ yield }.call
  return 1
end

def bar
  foo { return 2 }
end

p bar

I think clearly speccing this behavior will help fix this

• lambda { m1 { m2 ... { .. return } ... } } <-- should capture return .. correct?
• lambda { m1 { m2 ... { .. no return here .. } ... } } <-- should not capture returns .. correct?

If this is indeed the right thing, then lexical scoping checks in IRRuntimeHelpers while the return is bubbling might work. Will require twidding some things in there (not sure if the IRReturnJump object needs more state).

I have a fix locally. I think we've determined the logic is that return always goes to the nearest return-capturing lexical enclosure.

The fix makes the original case pass along with every other case we've formulated, and appears to pass tests. I'll push momentarily.

@subbuss I'd appreciate your review if you get a chance!

Seems reasonable to me.

Awesome, thanks for the quick fix! ❤️