Alan Wu 2699e230e4

Crash instead of raising with Check_Type() in RBIMPL_ASSERT_TYPE() in debug builds ...

Previously, RBIMPL_ASSERT_TYPE() used Check_Type() only in RUBY_DEBUG
builds. It raised TypeError, but only in debug builds. For people testing
type mismatch using debug builds looking for a Ruby exception, this can
be misleading -- the code could be missing a type check in non-debug builds
if it is relying on for example RSTRING_LEN() to raise.

Also, Check_Type() can obscure the true cause of error in debug mode.
When type check fails because the object is corrupt, instead of crashing
with a clear type assertion message, it can crash while trying to
construct an exception object to raise. You can see this for example in
<https://github.com/ruby/ruby/actions/runs/9489999591/job/26152506434?pr=10985>,
where RB_ENCODING_GET() is used on a corrupt object, but the crash
happens later and says "Assertion Failed:
../src/vm_method.c:1477:callable_method_entry_or_negative".
RBIMPL_ASSERT_TYPE() should assert right away.

RBIMPL_ASSERT_OR_ASSUME() asserts when RUBY_DEBUG and assumes in release
builds, as desired.

This should help investigate flaky CI failures that show up as TypeError
from `Kernel#require`, e.g.
"'Kernel#require': wrong argument type false (expected String) (TypeError)".

Same CI failure examples:
 - https://github.com/ruby/ruby/actions/runs/9034787861/job/24828147431
 - https://github.com/ruby/ruby/actions/runs/9418303667/job/25945492440
 - https://github.com/ruby/ruby/actions/runs/9505650952/job/26201031314

The failure occurs with and without use of YJIT.

2024-06-13 21:43:41 +00:00

..

ruby

Crash instead of raising with Check_Type() in RBIMPL_ASSERT_TYPE() in debug builds

2024-06-13 21:43:41 +00:00

ruby.h

…