You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A native method cannot tell a positional Hash from keyword arguments, and raise's cause: pays for it #873
A native method cannot tell a positional Hash from keyword arguments. It
receives args []object.Value with a trailing *object.Hash either way, and object.Hash carries no marker, so these two calls are indistinguishable inside
a native:
raise("message",{cause: RuntimeError.new})# TWO POSITIONAL argumentsraise("message",cause: RuntimeError.new)# one argument and a keyword
MRI answers differently: the first is a message plus a second positional
argument that is not an exception class, so it is TypeError: exception class/object expected; the second raises a RuntimeError
with that cause.
so it fails wherever rbgo's cause handling runs. That is core/kernel/raise_spec.rb, core/fiber/raise_spec.rb, and — since #872 gave Thread#raise the same cause: support — core/thread/raise_spec.rb as well, twice over there
because the shared block is included twice.
⛔ Before #872, Thread#raisepassed that example, and it passed because
of a defect: it ignored cause: entirely, so there was no trailing Hash to
mispop. Trading it for the 17 examples the cause: keyword actually fixes is
the right trade, but it should be recorded as a trade and not as a clean win.
Scope
Fixing it means marking keyword arguments at the call boundary so a native can
ask — a change to the call path and to every native that inspects a trailing
Hash, not something a cause-handling patch can do locally. Filing rather than
fixing in place, since the defect is older than the change that exposed it and
wider than raise.
Activity
Mark the positional-Hash limit #873 where it bites
Ruby 4.0 parity: Binding's implicit-parameter API and Thread#raise's …