Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Posible compilation issue #2954
I've recently hit very strange JRuby behavior when developing new synchronization layer in
The code seems to be working fine until it's compiled then it breaks. When
Following change is enough to break it, see pitr-ch/concurrent-ruby@c306a67 It fails on JRuby 1.7.19,20
Steps to reproduce:
It looks like the body of the
Well I was not able to reproduce so far. I get a different error regardless of command-line params:
I did not see anything obviously wrong by reading the bytecode, but I'm also not quite sure what I'm looking for.
You say that it appears that the body of the
I need your assistance to reproduce this on 1.7. Very much want to fix.
When it enters
I believe I have a trivial reproduction:
def foo(&a) while true return 1 end end p foo
This will not output anything because the
This behavior is triggered by having a while loop and a block capture argument (the
I think this may have been a mistake about nonlocal flow control in the past; specifically, I think I may have believed at the time that if the block contained a "break" or "next", those should jump based on the the loop within which the block was called. This is not the case.
Here we see that the non-local break inside the
I will try removing this behavior, run some tests, and also try to figure out if I had any other reason for doing this.
Well the only case I could find that breaks when I change this is a test case that never actually tested what we thought it did:
In 1.8.7, the break from the eval bubbles out and eventually breaks from the foo call; not from the while. In Ruby 1.9+, eval no longer is allowed to contain loose breaks like this, and with my change both 1.8 and 1.9 modes raise this error.
If I leave the code as is, we still don't behave like 1.8.7, and the break breaks out of the loop instead of out of foo:
Since doing a loose break in an eval has never really been approved behavior, and it is officially an error in 1.9.3+, I'm going to remove this logic.
Ok, this is fixed, and the specs run fine with
@enebo I know you may be concerned about this change, so we'll talk about whether we want to roll it into a 1.7.25 after we see how travis looks. Unfortunately 1.7 travis does not run a lot of JIT tests, but I feel pretty good about this change, especially given that it was very broken before.