Assigning regex with let causes spec to fail - unless the variable is invoked prior to use.

[forforf]

Stackoverflow question with code to reproduce the issue:

In a nutshell, if I assign a regex with a capture using a let statement. Something like this:

 let(:my_matcher) { /RegexWithCapture(\d)/ }

Then it fails in the it block when I actually try to use my_matcher

 "RegexWithCapture7".match(my_matcher)[1].should == 7  
 #=> fails
 #=> NoMethodError:  undefined method `[]' for /RegexWithCapture(\d)$/:Regexp

But!, If I invoke the matcher prior to using it, everything works as I'd expect.

my_matcher  #just invoking it does the trick
"RegexWithCapture7".match(my_matcher)[1].should == 7  
 #=> passes

I haven't tested the above code, I'm just using it to explain the problem but the stackoverflow question has an actual reproducible case. Here's a Gist with the same code as the SO question: https://gist.github.com/forforf/5112445 it's a bit easier to read.

I'm really curious why the behavior changes by just invoking the let variable.

Ruby 1.9.3 & RSpec 2.13.0 fwiw.

[cupakromer]

A few notes I found. This is not an issue with Ruby 2.0.0 and RSpec 2.13.0.

If you reverse the string and matcher, the test passes

# Ruby 1.9.3p392
describe "issue_820" do

  let(:my_matcher) { /RegexWithCapture(\d)/ }

  context "string.match matcher"
    it "correctly sets the capture with expect" do
      expect("RegexWithCapture7".match(my_matcher)[1]).to eq "7"
    end
    # issue_820 string.match matcher correctly sets the capture with expect
    #    Failure/Error: expect("RegexWithCapture7".match(my_matcher)[1]).to eq "7"
    #    NoMethodError:
    #      undefined method `[]' for /RegexWithCapture(\d)/:Regexp

    it "correctly sets the capture using should" do
      "RegexWithCapture7".match(my_matcher)[1].should eq "7"
    end
    # issue_820 string.match matcher correctly sets the capture using should
    #    Failure/Error: "RegexWithCapture7".match(my_matcher)[1].should eq "7"
    #    NoMethodError:
    #      undefined method `[]' for /RegexWithCapture(\d)/:Regexp
  end

  context "matcher.match string"
    it "correctly sets the capture using should" do
      expect(my_matcher.match("RegexWithCapture7")[1]).to eq "7"
    end
    # Passed

    it "correctly sets the capture using should" do
      my_matcher.match("RegexWithCapture7")[1].should eq "7"
    end
    # Passed
  end

end

[cupakromer]

So I've narrowed this down to the super() chain call in lib/rspec/core/memoized_helpers.rb#L157.

At this time, I'm not sure if issue #821 will fix this.

[myronmarston]

@cupakromer -- good sleuthing!

I'm puzzled by this, too; in my playing with it, there are basic things I take for granted about variables and object references in ruby that appear to be violated by this...it makes me wonder if it's a bug in ruby itself.

[myronmarston]

OK, I've isolated this to a very small example:

class Base
  define_method :regex do
    /^[a-z]+(\d)$/
  end
end

class Group < Base
  def self.let(name, &block)
    define_method(name) { super() }
  end

  let(:regex) {/^[a-z]+(\d)$/}
end

puts "abcdef8".match(Group.new.regex)[1]

[myronmarston]

I wrote up a gist with an isolated example and have asked some folks who know ruby better than I do to take a look at it.

[cupakromer]

That was the route I was heading. When I saw it worked in 2.0.0 and the code was just some usage of define_method it seemed odd. Esp, considering every time I just took a peak at the variable (in pry, with puts, etc) things would magically work. True Heisenbug.

As for a temp fix, it seems we can resolve the issue by not passing the block directly to define_method on the parent module. Instead we create a new closure which calls the block:

#  lib/rspec/core/memoized_helpers.rb#L152
MemoizedHelpers.module_for(self).define_method(name) do
  block.call
end

[cupakromer]

Based on the comments on the gist, I'm wondering if Peter is on to something with the need for a binding?

[myronmarston]

That change will break the support for super and return in let declarations that got added in 2.13. These method constructs can only be used if you pass the block directly to define_method. That's the entire reason there's the ancestor module.

I noticed that forcing a nil block using super(&nil) appears to solve it. Want to take a stab at fixing it with that?

Sent from my iPhone

On Mar 9, 2013, at 11:09 AM, Aaron Kromer notifications@github.com wrote:

That was the route I was heading. When I saw it worked in 2.0.0 and the code was just some usage of define_method it seemed odd. Esp, considering every time I just took a peak at the variable (in pry, with puts, etc) things would magically work. True Heisenbug.

As for a temp fix, it seems we can resolve the issue by not passing the block directly to define_method on the parent module. Instead we create a new closure which calls the block:

lib/rspec/core/memoized_helpers.rb#L152

MemoizedHelpers.module_for(self).define_method(name) do
block.call
end
—
Reply to this email directly or view it on GitHub.

[cupakromer]

Sure. I won't be able to get to it until tomorrow though.

[forforf]

Some additional information.
The issue occurs with string#match, but not string#scan. Also, since the issue occurs in 1.9.3 but not 2.0 I did a diff of the 1.9.3 string#match with the 2.0 string#match, the snippet of the difference is below:
I'm not sure what rb_check_arity does, but maybe it provides some clue as to what's going on.

1.9.3

if (argc < 1)
    rb_check_arity(argc, 1, 2);
re = argv[0];

2.0

if (argc < 1)
   rb_raise(rb_eArgError, "wrong number of arguments (%d for 1..2)", argc);
re = argv[0];