The change in ea15ceddbef2cc4c459c1ad5796e43ae9fa2cbf1 to use rb_yield_force_blockarg changes the behavior of returns called inside a passed lambda function. In 2.5.1 and below, including before the enum.c change, the attached script would print true. In 2.5.3 it prints false.
In ruby 2.4, the passed lambda now treats arguments like a normal lambda (it won't splat them). I think this is a good change (but that could be a debate). This is the complaint in #14639
2.4.4
Array#map
args 💣 wrong number of arguments (given 1, expected 2)
return ✅ lambda return semantics
Enumerable#map
args 💣 wrong number of arguments (given 1, expected 2)
return ✅ lambda return semantics
Array#each
args 💣 wrong number of arguments (given 1, expected 2)
return ✅ lambda return semantics
Array#map!
args 💣 wrong number of arguments (given 1, expected 2)
return ✅ lambda return semantics
In ruby 2.5.3 and in 2.6.0-preview3, Array#map was changed to always treat the passed lambda as a block. This changed both how it treats arguments (the desired change) and how it treats return (this bug).
In addition, it only made this change to Array#map aka Array#collect, which now doesn't match similar methods like Enumerable#map or Array#each or Array#map!. It's also a weird behaviour to have since it would be hard to write a custom MyClass#map in ruby which behaved the same way.
2.6.0
Array#map
args ✅
return ❌ block return semantics
Enumerable#map
args 💣 wrong number of arguments (given 1, expected 2)
return ✅ lambda return semantics
Array#each
args 💣 wrong number of arguments (given 1, expected 2)
return ✅ lambda return semantics
Array#map!
args 💣 wrong number of arguments (given 1, expected 2)
return ✅ lambda return semantics
I think both r64996 (for 2.5.x) and r63030 should be reverted.