From 47141797bed55eb10932c9a722a5132f50d4f3d8 Mon Sep 17 00:00:00 2001 From: Yusuke Endoh Date: Mon, 16 Mar 2020 23:03:22 +0900 Subject: hash.c: Do not use the fast path (rb_yield_values) for lambda blocks As a semantics, Hash#each yields a 2-element array (pairs of keys and values). So, `{ a: 1 }.each(&->(k, v) { })` should raise an exception due to lambda's arity check. However, the optimization that avoids Array allocation by using rb_yield_values for blocks whose arity is more than 1 (introduced at b9d29603375d17c3d1d609d9662f50beaec61fa1 and some commits), seemed to overlook the lambda case, and wrongly allowed the code above to work. This change experimentally attempts to make it strict; now the code above raises an ArgumentError. This is an incompatible change; if the compatibility issue is bigger than our expectation, it may be reverted (until Ruby 3.0 release). [Bug #12706] --- internal/proc.h | 1 + 1 file changed, 1 insertion(+) (limited to 'internal') diff --git a/internal/proc.h b/internal/proc.h index 864392906b..35bc43a4ee 100644 --- a/internal/proc.h +++ b/internal/proc.h @@ -17,6 +17,7 @@ struct rb_iseq_struct; /* in vm_core.h */ /* proc.c */ VALUE rb_proc_location(VALUE self); st_index_t rb_hash_proc(st_index_t hash, VALUE proc); +int rb_block_pair_yield_optimizable(void); int rb_block_arity(void); int rb_block_min_max_arity(int *max); VALUE rb_block_to_s(VALUE self, const struct rb_block *block, const char *additional_info); -- cgit v1.2.3