Actions
Bug #10929
closedNilClass#to_proc and & don't mix?
Description
This is sort of like a "who would ever care" kind of bug. Nonetheless technically it seems like it is one. So I thought it best that I report it just the same.
class NilClass
def to_proc
Proc.new{ |*x| nil }
end
end
def f(&b)
b.call(1)
end
f(&nil)
=> NoMethodError: undefined method `call' for nil:NilClass
(Maybe it was fixed already. Filing out this issue reminded me I need to update my version of Ruby.)
Files
Updated by hanachin (Seiei Miyagi) over 9 years ago
- File block_from_nil.patch block_from_nil.patch added
I wrote a patch for this issue.
diff --git bootstraptest/test_block.rb bootstraptest/test_block.rb
index cdc5960..4347fdd 100644
--- bootstraptest/test_block.rb
+++ bootstraptest/test_block.rb
@@ -611,3 +611,17 @@ assert_equal 'ok', %q{
end
'ok'
}
+
+assert_equal 'ok', %q{
+ class NilClass
+ def to_proc
+ Proc.new {|x| x }
+ end
+ end
+
+ def foo(&blk)
+ blk.call('ok')
+ end
+
+ foo(&nil)
+}, '[ruby-core:68384] [Bug #10929]'
diff --git vm_args.c vm_args.c
index cf7256b..e1cb8ac 100644
--- vm_args.c
+++ vm_args.c
@@ -755,7 +755,7 @@ vm_caller_setup_arg_block(const rb_thread_t *th, rb_control_frame_t *reg_cfp, rb
proc = *(--reg_cfp->sp);
- if (proc != Qnil) {
+ if (proc != Qnil || rb_respond_to(Qnil, idTo_proc)) {
if (!rb_obj_is_proc(proc)) {
VALUE b;
Updated by ko1 (Koichi Sasada) over 9 years ago
- Assignee set to matz (Yukihiro Matsumoto)
I'm not sure we support it or not.
For me, it is easy to understand that passing nil
is special case, passing no block.
Updated by mame (Yusuke Endoh) almost 5 years ago
- Status changed from Open to Feedback
The suggested change is harmful. It will break delegation: def foo(&blk); bar(&blk); end; foo()
.
Ruby allows redefinition of Integer#/
which is incredibly harmful, so it is possible to allow NilClass#to_proc
. But do you really want to allow that?
Updated by ko1 (Koichi Sasada) almost 5 years ago
- Status changed from Feedback to Rejected
it can break delegation methods.
Actions
Like0
Like0Like0Like0Like0