Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jRuby 9050 and 9100 behave differently for case / when with Array from MRI #3897

Closed
yoshidajun opened this issue May 17, 2016 · 7 comments
Closed

Comments

@yoshidajun
Copy link

Environment:

jruby-9.0.5.0
jruby-9.1.0.0
ruby-2.2.4 ( MRI )

  • Mac OS X ( 10.11.4 El Capitan )
  • RVM 1.26.11
  • irb to run the code

Problem:

The following code returns different results between jRuby and MRI.

ALL = ['v0', 'v1']
vs = ['v0', 'v1']

case vs
when ALL then 1234
else
  raise 'Undefined'
end
  • MRI ( 2.2.4 ) returns 1234 ( good )
  • jRuby ( 9.0.5.0, 9.1.5.0 ) raises RuntimeError: 'Undefined' ( why? )

Stacktrace:

RuntimeError: Undefined
    from (irb):7:in `<eval>'
    from org/jruby/RubyKernel.java:983:in `eval'
    from org/jruby/RubyKernel.java:1290:in `loop'
    from org/jruby/RubyKernel.java:1103:in `catch'
    from org/jruby/RubyKernel.java:1103:in `catch'
    from /Users/yjun/.rvm/rubies/jruby-9.1.0.0/bin/irb:13:in `<top>'

Another code using if / else:

ALL = ['v0', 'v1']
vs = ['v0', 'v1']

if ALL === vs
  1234
else
  raise 'Undefined'
end

=> This code returns the same result ( 1234: good ).

I thought case a when b then c else d end is equivalent to if b === a then c else d end.
But it doesn't look like so.

Is this a known issue?

@headius
Copy link
Member

headius commented May 17, 2016

Ah-ha...you may have found the source of pesky "Undefined" errors we have not been able to reproduce. Apparently this form is not particularly common?

This definitely needs to be fixed.

@headius
Copy link
Member

headius commented May 17, 2016

Oops...nevermind...the "Undefined" errors I've seen are unrelated to your script.

But yes, this is still a bug.

@yoshidajun
Copy link
Author

Thank you for your confirmation!

I'll fix my application's code to avoid that for now.
Looking forward to the bug fixed. :-)

@headius
Copy link
Member

headius commented May 17, 2016

cc @enebo and @subbuss since this is obviously a behavior issue in IR (JIT and interp both behave the same).

@headius headius added the ir label May 17, 2016
@subbuss
Copy link
Contributor

subbuss commented May 18, 2016

The case-when construct uses IRRuntimeHelpers.isEQQ (via EQQInstr) and the if-then-else construct uses the Array.=== call. So, maybe the isEQQ implementation has a bug in some corner-case.

@headius
Copy link
Member

headius commented May 18, 2016

@subbuss I think the problem is that the IR does not distinguish between these two whens:

ary = [1,2,3]
case x
when 1,2,3
  # 1, 2, 3 should each be used to === in turn
when ary
  # Array#== should be called once
end

Both cases fall into isEQQ with a RubyArray, but the second case isn't supposed to === over the elements.

rescue may have a similar bug.

@enebo enebo added this to the JRuby 9.1.9.0 milestone Mar 14, 2017
@enebo
Copy link
Member

enebo commented Mar 14, 2017

I just tested the original case and we seem to be passing it now. I am guessing this got fixed via another issue at some point in the past.

@enebo enebo closed this as completed Mar 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants