1
0
Fork 0
mirror of https://github.com/ruby/ruby.git synced 2022-11-09 12:17:21 -05:00
ruby--ruby/test/ruby/test_undef.rb

55 lines
784 B
Ruby
Raw Normal View History

# frozen_string_literal: false
require 'test/unit'
class TestUndef < Test::Unit::TestCase
class Undef0
def foo
"foo"
end
undef foo
end
class Undef1
def bar
"bar"
end
end
class Undef2 < Undef1
undef bar
end
def test_undef
x = Undef0.new
assert_raise(NoMethodError) { x.foo }
y = Undef1.new
assert_equal "bar", y.bar
z = Undef2.new
assert_raise(NoMethodError) { z.bar }
end
def test_special_const_undef
assert_raise(TypeError) do
1.instance_eval do
undef to_s
end
end
end
Lazily create singletons on instance_{exec,eval} (#5146) * 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>
2021-12-02 18:53:39 -05:00
def test_singleton_undef
klass = Class.new do
def foo
:ok
end
end
klass.new.foo
klass.new.instance_eval do
undef foo
end
klass.new.foo
end
end