They are no longer how Object#clone/Object#dup are defined. In fact
DUPSETUP is not used from anywhere. CLONESETUP has only one usage.
Let's not expose them to extension libraries.
cf https://github.com/ruby/ruby/pull/4100#discussion_r563481718
Previously, due to a change to fix bug 15608, Method#inspect output
changed for class methods:
Ruby 2.7
"#<Method: String.prepend(*)>"
Before change:
"#<Method: #<Class:Object>(Module)#prepend(*)>"
This is wrong because the Method object was created from String and
not Object. This is because the fix for bug 15608 assumed it was
being called on the singleton class of a instance, and would skip
the first singleton class until it got to the class itself. For
class methods, this results in always using the superclass. Fix
behavior to not skip until the superclass if the singleton class
is the singleton class of a module or class.
After change:
"#<Method: #<Class:Object>(Module)#prepend(*)>"
Fixes [Bug #17428]
lambda(&b) where b is given block of method (like: def foo(&b))
should warn correctly.
[Feature #17361]
Also labmda(&labmda_block) or lambda(&:to_s) (Symbol#to_proc)
should not warn (but I'm not sure who cares about it).
* `GC.auto_compact=`, `GC.auto_compact` can be used to control when
compaction runs. Setting `auto_compact=` to true will cause
compaction to occurr duing major collections. At the moment,
compaction adds significant overhead to major collections, so please
test first!
[Feature #17176]
Previously, Method#super_method looked at the called_id to
determine the method id to use, but that isn't correct for
aliased methods, because the super target depends on the
original method id, not the called_id.
Additionally, aliases can reference methods defined in other
classes and modules, and super lookup needs to start in the
super of the defined class in such cases.
This adds tests for Method#super_method for both types of
aliases, one that uses VM_METHOD_TYPE_ALIAS and another that
does not. Both check that the results for calling super
methods return the expected values.
To find the defined class for alias methods, add an rb_ prefix
to find_defined_class_by_owner in vm_insnhelper.c and make it
non-static, so that it can be called from method_super_method
in proc.c.
This bug was original discovered while researching [Bug #11189].
Fixes [Bug #17130]
Not every compilers understand that rb_raise does not return. When a
function does not end with a return statement, such compilers can issue
warnings. We would better tell them about reachabilities.
Previously, these were not implemented, and Object#== and #eql?
were used. This tries to check the proc internals to make sure
that procs created from separate blocks are treated as not equal,
but procs created from the same block are treated as equal, even
when the lazy proc allocation optimization is used.
Implements [Feature #14267]
If you look at the code flow (break -> goto), this assignment never
makes any sense. Should just remove.
I _guess_ this behaviour is unintended. Original code at commit
4dc1a2180946ab793adee5eb235fc4ee8fa4cefe did something. It might be
the code flow that is buggy. However rubyspec already includes this
particular edge case at ruby/core/module/undef_method_spec.rb. I don't
think we can change the way it is any longer.
For ZSUPER methods with no defined class for the method entry, start the next lookup at the superclass of the origin class of the method owner, instead of the superclass of the method owner.
Fixes [Bug #16942]
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]
Previously, if an object has a singleton class, and you call
Object#method on the object, the resulting string would include
the object's singleton class, even though the method was not
defined in the singleton class.
Change this so the we only show the singleton class if the method
is defined in the singleton class.
Fixes [Bug #15608]
This removes the warnings added in 2.7, and changes the behavior
so that a final positional hash is not treated as keywords or
vice-versa.
To handle the arg_setup_block splat case correctly with keyword
arguments, we need to check if we are taking a keyword hash.
That case didn't have a test, but it affects real-world code,
so add a test for it.
This removes rb_empty_keyword_given_p() and related code, as
that is not needed in Ruby 3. The empty keyword case is the
same as the no keyword case in Ruby 3.
This changes rb_scan_args to implement keyword argument
separation for C functions when the : character is used.
For backwards compatibility, it returns a duped hash.
This is a bad idea for performance, but not duping the hash
breaks at least Enumerator::ArithmeticSequence#inspect.
Instead of having RB_PASS_CALLED_KEYWORDS be a number,
simplify the code by just making it be rb_keyword_given_p().
Saves comitters' daily life by avoid #include-ing everything from
internal.h to make each file do so instead. This would significantly
speed up incremental builds.
We take the following inclusion order in this changeset:
1. "ruby/config.h", where _GNU_SOURCE is defined (must be the very
first thing among everything).
2. RUBY_EXTCONF_H if any.
3. Standard C headers, sorted alphabetically.
4. Other system headers, maybe guarded by #ifdef
5. Everything else, sorted alphabetically.
Exceptions are those win32-related headers, which tend not be self-
containing (headers have inclusion order dependencies).
Before this commit, Kernel#lambda can't tell the difference between a
directly passed literal block and one passed with an ampersand.
A block passed with an ampersand is semantically speaking already a
non-lambda proc. When Kernel#lambda receives a non-lambda proc, it
should simply return it.
Implementation wise, when the VM calls a method with a literal block, it
places the code for the block on the calling control frame and passes a
pointer (block handler) to the callee. Before this commit, the VM
forwards block arguments by simply forwarding the block handler, which
leaves the slot for block code unused when a control frame forwards its
block argument. I use the vacant space to indicate that a frame has
forwarded its block argument and inspect that in Kernel#lambda to detect
forwarded blocks.
This is a very ad-hoc solution and relies *heavily* on the way block
passing works in the VM. However, it's the most self-contained solution
I have.
[Bug #15620]
This allows passing keywords through a normal argument splat in a
Proc. While needing ruby2_keywords support for methods is more
common, there is code that delegates keywords through normal
argument splats in procs, including code in Rails. For that
reason, it makes sense to expose this for procs as well.
Internally, ruby2_keywords is not tied to methods, but iseqs,
so this just allows for setting the ruby2_keywords for the iseq
related to the proc.
