Towards gems - obscure scoping bug

Ruby IronRuby
1

module A
Default = 42
def A::foo
end

def A::meth1(param = Default)
foo {}
puts ‘OK’
end

def A::meth2(param = Default)
puts ‘not OK’
foo { foo {} }
end

A::meth1()
A::meth2()
end

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.

2

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: [email protected]
[[email protected]] On Behalf Of Wayne K.
[[email protected]]
Sent: Thursday, 21 February 2008 12:12 AM
To: [email protected]
Subject: [Ironruby-core] Towards gems - obscure scoping bug

module A
Default = 42
def A::foo
end

def A::meth1(param = Default)
foo {}
puts ‘OK’
end

def A::meth2(param = Default)
puts ‘not OK’
foo { foo {} }
end

A::meth1()
A::meth2()
end

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
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core