Caused by 04a92a6764bf678919cf4b68a27496a39d6b886a. This treats
unbounded ranges of arbitrary objects the same as how unbounded
string ranges are treated:
(..x) === y # (y <=> x) <= 0
(...x) === y # (y <=> x) < 0
(x..) === y # (x <=> y) <= 0
Fixes [Bug #19864]
On Range#bsearch for endless ranges, we try positions at `begin + 2**i` (i = 0, 1, 2, ...)
to find a point that satisfies a given condition.
Subsequently, we perform binary searching with the interval `[begin, begin + 2**n]`.
However, the interval `[begin + 2**(n-1), begin + 2**n]` is sufficient for binary search
because `begin + 2**(n-1)` does not satisfy the condition.
The same applies to beginless ranges.
* YJIT: Avoid creating a vector in get_temp_regs()
Co-authored-by: Alan Wu <alansi.xingwu@shopify.com>
* Remove unused import
---------
Co-authored-by: Alan Wu <alansi.xingwu@shopify.com>
Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>
Yet another partial revert of https://github.com/ruby/ruby/pull/8329,
similar to 00f263e6c4.
Repro: On ruby/ruby@1be64e34d0, `tool/sync_default_gems.rb yarp
162c2088eec6ec8f0558559e082cd661c18ee02a` should exist successfully, but
it doesn't without this gem-specific handling.
Since the compile-time iseq used in the guard was not marked and updated
during compaction, a runtime value reusing the address could falsely pass
the guard.
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
This commit changes the node template to create a dispatcher class,
which can be used to walk an AST an emit events to all registered
listeners
https://github.com/ruby/yarp/commit/03a45f85e6
Co-authored-by: Kevin Newton <kddnewton@users.noreply.github.com>
Since the hashes have a default proc that returns a (new) empty hash, we
can avoid allocating those empty hashes when we are only doing lookups.
Test from running `bundle update --bundler` against a rails app I have
lying around:
```
==> memprof.after.txt <==
Total allocated: 9.71 MB (68282 objects)
Total retained: 4.87 MB (33791 objects)
==> memprof.before.txt <==
Total allocated: 10.83 MB (100596 objects)
Total retained: 5.02 MB (34721 objects)
```
https://github.com/rubygems/rubygems/commit/8f7c9cb23e
Running `bundle update --bundler` on a rails app locally:
```
==> memprof.after.txt <==
Total allocated: 301.90 kB (3794 objects)
Total retained: 73.24 kB (698 objects)
==> memprof.before.txt <==
Total allocated: 14.47 MB (196378 objects)
Total retained: 25.93 kB (202 objects)
```
So for a slight increase in retained memory (all keys are now retained),
we go from about 200k allocations in the settings file to under 4k
https://github.com/rubygems/rubygems/commit/e64debb6ae
Frames pushed by YJIT have an unreliable PC. The PC could be garbage,
and if we try to read the line number with a garbage PC, then the
program can crash.
This commit returns line 0 for programs where there is a `jit_return`
function. If `jit_return` has been set then this frame was pushed by
the JIT, and we cannot trust the PC.
Here is a debugger session for a program that crashed due to a broken
PC:
```
(lldb) p ruby_current_vm_ptr->ractor.main_thread->ec->cfp->iseq->body->iseq_encoded
(VALUE *) $0 = 0x0000000118a30e00
(lldb) p/x ruby_current_vm_ptr->ractor.main_thread->ec->cfp->pc
(const VALUE *) $1 = 0x0000600000b02d00
(lldb) p/x ruby_current_vm_ptr->ractor.main_thread->ec->cfp->jit_return
(void *) $2 = 0x000000010622942c
```
You can see the PC is completely out of range, but there is a
`jit_return` pointer so we can avoid this crash.
