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

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin11.4.0]

[myronmarston (Myron Marston)]

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
/^(\d)$/
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(/^(\d)$/).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:
/^(\d)$/

String#match(regex) returns a MatchData object:
#<MatchData "8" 1:"8">

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:
#<MatchData "8" 1:"8">

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!

[jsc (Justin Collins)]

The example appears to have been a little mangled on Redmine.

This code reproduces the issue on 1.9.3-p327 and 1.9.3-p551:

class Superclass
  define_method :regex do
    /^(\d)$/
  end
end

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

  override(:regex) { }
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(/^(\d)$/).inspect
puts
puts "But somehow, when I combine these, I can get nil:"
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

The output is:

Subclass.new.regex returns a regular expression object:
/^(\d)$/

String#match(regex) returns a MatchData object:
#<MatchData "8" 1:"8">

But somehow, when I combine these, I can get nil:
nil

Unless I add a tap block that does nothing:
#<MatchData "8" 1:"8">

As noted, the bug was already fixed in 2.0+. As the possibility of another 1.9.3 is extremely unlikely, I guess this issue can be closed.

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Closed

Thank you for the confirmation.