def _generate
var = 110
proc {|hoge| p local_variables }
end
_generate.call
outputs [:hoge], but I expect [:hoge, :var] as CRuby does.
As I looked the code, struct REnv * assigned to the generated proc gets unshared when cipop called in OP_RETURN, and that makes the env not enumarated. Is this a mruby's spec or not?
Even if that's a spec, I believe that the following behavior is absolutely a bug.
def _generate
eval("var = 110; proc {|hoge| p local_variables }")
end
def _call(invisible)
invisible.call
end
_call(_generate)
says [:hoge, :invisible], but if I'm correct invisible shouldn't appear.
In this case, the env of the generated proc is not unshared due to another callinfo, but mrb_local_variables refers current callinfo stack, so variables not related to the proc appears. As a similar example,
def _generate
eval("var = 110; proc {|hoge| p local_variables }")
end
def dummy(invisible)
end
Fiber.new {
ret = _generate
dummy(nil)
ret
}.resume.call
outputs the same, [:hoge, :invisible]. In this case, another context's callinfo which gets overwrited by calling dummy function is referred.
outputs
[:hoge], but I expect[:hoge, :var]as CRuby does.As I looked the code,
struct REnv *assigned to the generated proc gets unshared when cipop called in OP_RETURN, and that makes the env not enumarated. Is this a mruby's spec or not?Even if that's a spec, I believe that the following behavior is absolutely a bug.
says
[:hoge, :invisible], but if I'm correctinvisibleshouldn't appear.In this case, the env of the generated proc is not unshared due to another callinfo, but mrb_local_variables refers current callinfo stack, so variables not related to the proc appears. As a similar example,
outputs the same,
[:hoge, :invisible]. In this case, another context's callinfo which gets overwrited by callingdummyfunction is referred.