[Ironruby-core] Towards gems - obscure scoping bug

Wayne Kelly w.kelly at qut.edu.au
Wed Feb 20 18:47:43 EST 2008

I think I've tracked down the cause of this scoping bug. The meth2 body is executed, but unlike the meth1 body, this time a NestedCodeContext is created. It appears the problem is that RubyHelpers.CreateNestedCodeContext doesn't set the parent property of the nested context to the containing context that is passed to it as a parameter. Adding a new CodeContext constructor with an extra parent parameter appears to make the problem go away, at least in my example.

Cheers, Wayne.
From: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly [w.kelly at qut.edu.au]
Sent: Thursday, 21 February 2008 12:12 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Towards gems - obscure scoping bug

module A
  Default = 42
  def A::foo

  def A::meth1(param = Default)
    foo {}
    puts 'OK'

  def A::meth2(param = Default)
    puts 'not OK'
    foo { foo {} }



The first method executes OK, however, the second method fails when trying to lookup the Default constant for the unspecified param. Even though the body of the second method is never executed, the  mere presence of the nested blocks causes the context scoping to get screwed up so that the second method appears to be nested directly within the global scope rather than with the scope of the module A where  the constant is defined.

BTW, these and other errors that I've been reporting aren't just random bugs, they're bugs that I've come across in my on going efforts to get gems setup running under IronRuby, so they are on the critical path to running Rails.

Cheers, Wayne.
Ironruby-core mailing list
Ironruby-core at rubyforge.org

More information about the Ironruby-core mailing list