[ruby-core:53271] [ruby-trunk - Bug #8059][Open] Unrelated block value returned by String#match(regex) when regex is returned by a method that uses define_method and super

[ruby-core:53271] [ruby-trunk - Bug #8059][Open] Unrelated block value returned by String#match(regex) when regex is returned by a method that uses define_method and super

[myronmarston (Myron Marston)]

Issue #8059 has been reported by myronmarston (Myron Marston).

----------------------------------------
Bug #8059: Unrelated block value returned by String#match(regex) when regex is returned by a method that uses define_method and super
https://bugs.ruby-lang.org/issues/8059

Author: myronmarston (Myron Marston)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 
ruby -v: ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin11.4.0]


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!


-- 
http://bugs.ruby-lang.org/

[ruby-core:91084] [Ruby trunk Bug#8059] Unrelated block value returned byString#match(regex) when regex is returned by a method that uses define_methodand super

[justin]

Issue #8059 has been updated by 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.

----------------------------------------
Bug #8059: Unrelated block value returned by String#match(regex) when regex is returned by a method that uses define_method and super
https://bugs.ruby-lang.org/issues/8059#change-76312

* Author: myronmarston (Myron Marston)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin11.4.0]
* Backport: 
----------------------------------------
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!



-- 
https://bugs.ruby-lang.org/

[ruby-core:91089] [Ruby trunk Bug#8059] Unrelated block value returned by String#match(regex) when regex is returned by a method that uses define_method and super

[nobu]

Issue #8059 has been updated by nobu (Nobuyoshi Nakada).

Status changed from Open to Closed

Thank you for the confirmation.

----------------------------------------
Bug #8059: Unrelated block value returned by String#match(regex) when regex is returned by a method that uses define_method and super
https://bugs.ruby-lang.org/issues/8059#change-76320

* Author: myronmarston (Myron Marston)
* Status: Closed
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin11.4.0]
* Backport: 
----------------------------------------
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!



-- 
https://bugs.ruby-lang.org/