Bug #8059

Unrelated block value returned by String#match(regex) when regex is returned by a method that uses define_method and super

Added by Myron Marston about 1 year ago.

[ruby-core:53271]
Status:Open
Priority:Normal
Assignee:-
Category:-
Target version:-
ruby -v:ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin11.4.0] Backport:

Description

This started as a stackoverflow question:

http://stackoverflow.com/questions/15283425/in-rspec-using-let-to-assign-a-regex-creates-unexpected-pass-fail-behavior-bu/15284031

...then became an rspec-core issue:

https://github.com/rspec/rspec-core/issues/820

...which led me to isolate the behavior into a standalone script, which I've posted as a gist with an ongoing discussion with @peterc and others:

https://gist.github.com/myronmarston/5123087

Here's a simplified version of the script from the gist (removing the ENV conditionals for clarity):

class Superclass
define_method :regex do
/\)$/
end
end

class Subclass < Superclass
def self.override(name)
define_method(name) { super() }
end

override(:regex) { :foo }
end

puts "Subclass.new.regex returns a regular expression object:"
puts Subclass.new.regex.inspect
puts
puts "String#match(regex) returns a MatchData object:"
puts "8".match(/\)$/).inspect
puts
puts "But somehow, when I combine these, I get the value passed to the override block:"
puts "8".match(Subclass.new.regex).inspect
puts
puts "Unless I add a tap block that does nothing:"
puts "8".match(Subclass.new.regex.tap { |s| }).inspect

And the output:

➜ ruby --version
ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin11.4.0]
➜ ruby foo.rb
Subclass.new.regex returns a regular expression object:
/\)$/

String#match(regex) returns a MatchData object:
#

But somehow, when I combine these, I get the value passed to the override block:
:foo

Unless I add a tap block that does nothing:
#

I can't even wrap my head around this behavior, it's so bizarre. It appears to be fixed in 2.0.

It's also a heisenbug -- the act of trying to inspect things using the tap block or set_trace_func causes the bug to go away.

I'd love to see this fixed in a future 1.9.3 patch release. More than that, I'm extremely curious what's causing this; it seems to violate my mental model of how ruby works so thoroughly!

Also available in: Atom PDF