`IO#reopen` internally uses dup syscall but some platforms don't support
the syscall. re-assigning `$stderr` is enough to capture the interpreter's
errors and warnings.
* Lazily create singletons on instance_{exec,eval}
Previously when instance_exec or instance_eval was called on an object,
that object would be given a singleton class so that method
definitions inside the block would be added to the object rather than
its class.
This commit aims to improve performance by delaying the creation of the
singleton class unless/until one is needed for method definition. Most
of the time instance_eval is used without any method definition.
This was implemented by adding a flag to the cref indicating that it
represents a singleton of the object rather than a class itself. In this
case CREF_CLASS returns the object's existing class, but in cases that
we are defining a method (either via definemethod or
VM_SPECIAL_OBJECT_CBASE which is used for undef and alias).
This also happens to fix what I believe is a bug. Previously
instance_eval behaved differently with regards to constant access for
true/false/nil than for all other objects. I don't think this was
intentional.
String::Foo = "foo"
"".instance_eval("Foo") # => "foo"
Integer::Foo = "foo"
123.instance_eval("Foo") # => "foo"
TrueClass::Foo = "foo"
true.instance_eval("Foo") # NameError: uninitialized constant Foo
This also slightly changes the error message when trying to define a method
through instance_eval on an object which can't have a singleton class.
Before:
$ ruby -e '123.instance_eval { def foo; end }'
-e:1:in `block in <main>': no class/module to add method (TypeError)
After:
$ ./ruby -e '123.instance_eval { def foo; end }'
-e:1:in `block in <main>': can't define singleton (TypeError)
IMO this error is a small improvement on the original and better matches
the (both old and new) message when definging a method using `def self.`
$ ruby -e '123.instance_eval{ def self.foo; end }'
-e:1:in `block in <main>': can't define singleton (TypeError)
Co-authored-by: Matthew Draper <matthew@trebex.net>
* Remove "under" argument from yield_under
* Move CREF_SINGLETON_SET into vm_cref_new
* Simplify vm_get_const_base
* Fix leaf VM_SPECIAL_OBJECT_CONST_BASE
Co-authored-by: Matthew Draper <matthew@trebex.net>
This changes the following warnings:
* warning: class variable access from toplevel
* warning: class variable @foo of D is overtaken by C
into RuntimeErrors. Handle defined?(@@foo) at toplevel
by returning nil instead of raising an exception (the previous
behavior warned before returning nil when defined? was used).
Refactor the specs to avoid the warnings even in older versions.
The specs were checking for the warnings, but the purpose of
the related specs as evidenced from their description is to
test for behavior, not for warnings.
Fixes [Bug #14541]
* class.c (rb_special_singleton_class_of): utility function.
* vm_eval.c (eval_under): special deal for class variable scope with
instance_eval.
* vm_eval.c (rb_obj_instance_eval, rb_obj_instance_exec): allow method
definition in instance_eval of special constants. [ruby-core:28324]
[Bug #2788]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@36647 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
th->base_block is information for (a) parsing, (b) compiling
and (c) setting up the frame to execute the program passed by
`eval' method. For example, (1) parser need to know up-level
variables to detect it is variable or method without paren.
Befor (a), (b) and (c), VM set th->base_block by passed bindng
(or previous frame information). After execute (a), (b) and (c),
VM should clear th->base_block. However, if (a), (b) or (c)
raises an exception, then th->base_block is not cleared.
Problem is that the uncleared value th->balo_block is used for
irrelevant iseq compilation. It causes SEGV or critical error.
I tried to solve this problem: to clear them before exception,
but finally I found out that it is difficult to do it (Ruby
program can be run in many places).
Because of this background, I set th->base_block before
compiling iseq and restore it after compiling.
Basically, th->base_block is dirty hack (similar to global
variable) and this patch is also dirty.
* bootstraptest/test_eval.rb: add a test for above.
* internal.h: remove unused decl.
* iseq.c (rb_iseq_compile_with_option): add base_block parameter.
set th->base_block before compation and restore it after
compilation.
* ruby.c (require_libraries): pass 0 as base_block instead of
setting th->base_block
* tool/compile_prelude.rb (prelude_eval): apply above changes.
* vm.c, vm_eval.c: ditto.
* vm_core.h: add comments.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@36179 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Divide big array (or hash) literals into several blocks and
concatetene them. There was a problem that a big array (hash)
literal causes SystemStackError exception (stack overflow)
because VM push all contents of the literal onto VM stack to
make an array (or hash). To solve this issue, we make several
arrays (hashes) and concatenate them to make a big array (hash)
object.
??
* compile.c (iseq_compile_each, setup_args): use modified
compile_array.
* vm.c (m_core_hash_from_ary, m_core_hash_merge_ary,
m_core_hash_merge_ptr): added for above change.
* id.c (Init_id), parse.y: add core method ids.
* bootstraptest/test_literal.rb: add simple tests.
* bootstraptest/test_eval.rb: remove rescue clause to catch
SystemStackError exception.
* test/ruby/test_literal.rb: add tests to check no stack overflow.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@35306 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* vm.c (vm_set_main_stack, rb_iseq_eval_main): added.
* parse.y (rb_parser_compile_file): fix to check parse_in_eval flag.
* eval.c (ruby_exec_node): use rb_iseq_eval_main()
instead of rb_iseq_eval().
* iseq.c (rb_iseq_new_main), vm_core.h: added.
main script (specified by -e or script name) should be run
under TOPLEVEL_BINDING using Kernel#eval. Above changes
simulate Kernel#eval behaviour. [ruby-dev:37240]
* compile.c (make_name_for_block): skip iseq except block type.
this fix is needed for [ruby-dev:37240], and also fixes
[ruby-dev:35392].
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@21079 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
set a VM_FRAME_FLAG_PASSED flag to skip this frame when
searching ruby-level-cfp.
* eval.c, eval_intern.h, proc.c: fix to check cfp. if there is
no valid ruby-level-cfp, cause RuntimeError exception.
[ruby-dev:34128]
* vm_core.h, vm_evalbody.c, vm.c, vm_dump.c, vm_insnhelper.c,
insns.def: rename FRAME_MAGIC_* to VM_FRAME_MAGIC_*.
* KNOWNBUGS.rb, bootstraptest/test*.rb: move solved bugs.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@17084 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
and cvar_base search protocol.
* bootstraptest/test_knownbug.rb, test_eval.rb: move soleved test
and add new tests.
* test/ruby/test_eval.rb: fix tests for spec.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@16486 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
from break/next, and COMPILE_ERROR() breaks only one block.
[ruby-dev:31372]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@14339 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
visibility again. we no longer provide __send, __send!.
* eval.c (rb_invoke_method): new method to honor private
visibility. if it's invoked in a function call style, it calls
private methods as well (previous 1.9 send behavior).
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@13824 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Yuta Saito