Came across the following bug in Ruby 1.8.6:
module M
def m
super
end
alias n m
end
class C
def m
1
end
end
class C1 < C
include M
end
p C1.new.m # => 1
p C1.new.n # => error
In Ruby 1.8.1, this last call returns 1.
I think this is a consequence of the fix to the bug I reported in
[rubycore:03672] a long time ago. The nd_orig field in a NODE_FBODY
refers to a module (M in the case above, could be an iclass in some
other cases, but that doesn't change anything because it would be the
wrong iclass), and from there the method that super refers to is
searched for, but as M has no superclass, it isn't found. The
search_iclass method used to translate this module to the appropriate
iclass, so it's its removal that broke things.
Note that HEAD gives the correct result for the program above, but the
wrong result for the program in [rubycore:03672]. Seems YARV still
employs search_iclass, albeit with the slightly different name
vm_search_normal_super_klass.
I believe to fix this in 1.8.6, it is sufficient to reinstate
search_iclass, but only in rb_call_super. Seems like the problem
reported in [rubycore:03672] can't occur for modules because of the
"dynamic module inclusion problem" (or "double inclusion problem")
that prevents me from using the trick in [rubycore:03672] to get the
module included twice, so the search_iclass should not cause problems.
I don't know enough of YARV to fix things there, but I suppose it
would be comparable to the fix in [rubycore:03672] together with the
fix to this. It's possible that the patch in [ruby-talk:248738] needs
to be ported as well because the fix for [rubycore:03672] broke
something else too.
Peter
on 11.09.2007 00:53
on 11.09.2007 02:22
Calamitas wrote: > I believe to fix this in 1.8.6, it is sufficient to reinstate > search_iclass, but only in rb_call_super. Seems like the problem > reported in [rubycore:03672] can't occur for modules because of the > "dynamic module inclusion problem" (or "double inclusion problem") > that prevents me from using the trick in [rubycore:03672] to get the > module included twice, so the search_iclass should not cause problems. I reported a similar issue with Object#method, see message [rubycore:11600] As far as I'm concerned, this behavior is busted; super should always go to the method of the same name in the superclass. aliasing the method should not change its behavior. - Charlie