* Sync YARP gemspec
We were previously not syncing the YARP gemspec over which meant
that the Ruby YARP gem was out of sync.
* Sync YARP node / lex_compat files
The problem was that we were treating heredoc bodies as part of the %W
list because we didn't push the scanning cursor past the heredoc after
lexing out the here doc. To fix this, we changed the whitespace
scanning function to quit scanning when it reaches a newline but only in
the case that a heredoc is present.
Additionally, we need to prevent double counting newlines in the case of
a heredoc. For example:
```ruby
%W(<<foo 123)
foo
```
The newline after the `)` is counted as part of scanning the heredoc, so
we added logic to prevent double counting the newline when scanning the
rest of the %W list.
https://github.com/ruby/yarp/commit/eb090d8126
Co-authored-by: Jemma Issroff <jemmaissroff@gmail.com>
In `JSON#generate` and `JSON#fast_generate`:
- When the given `opts` is a `JSON::State` the variable is set to
`nil`.
- But it will be never used as the next `if` blocks will not be
executed.
- `JSON::State#configure` does the conversion to `Hash`, the
conversions in the `if` block are just duplication.
- `JSON::State.new` does the same thing with `configure` when an
argument is given.
https://github.com/flori/json/commit/5d9ab87f8e
(https://github.com/ruby/irb/pull/648)
IRB already has several features that rely on rdoc, such as:
- Autocompletion's document dialog
- Autocompletion's `PerfectMatchedProc`
- The `show_doc` command
- Easter egg
And we could use its pager more in the future too. So it makes sense to
declare rdoc as a dependency instead of relying on the one bundled with
Ruby.
https://github.com/ruby/irb/commit/4dffbb1dd3
Remove rb_control_frame_t::__bp__ and optimize bmethod calls
This commit removes the __bp__ field from rb_control_frame_t. It was
introduced to help MJIT, but since MJIT was replaced by RJIT, we can use
vm_base_ptr() to compute it from the SP of the previous control frame
instead. Removing the field avoids needing to set it up when pushing new
frames.
Simply removing __bp__ would cause crashes since RJIT and YJIT used a
slightly different stack layout for bmethod calls than the interpreter.
At the moment of the call, the two layouts looked as follows:
┌────────────┐ ┌────────────┐
│ frame_base │ │ frame_base │
├────────────┤ ├────────────┤
│ ... │ │ ... │
├────────────┤ ├────────────┤
│ args │ │ args │
├────────────┤ └────────────┘<─prev_frame_sp
│ receiver │
prev_frame_sp─>└────────────┘
RJIT & YJIT interpreter
Essentially, vm_base_ptr() needs to compute the address to frame_base
given prev_frame_sp in the diagrams. The presence of the receiver
created an off-by-one situation.
Make the interpreter use the layout the JITs use for iseq-to-iseq
bmethod calls. Doing so removes unnecessary argument shifting and
vm_exec_core() re-entry from the interpreter, yielding a speed
improvement visible through `benchmark/vm_defined_method.yml`:
patched: 7578743.1 i/s
master: 4796596.3 i/s - 1.58x slower
C-to-iseq bmethod calls now store one more VALUE than before, but that
should have negligible impact on overall performance.
Note that re-entering vm_exec_core() used to be necessary for firing
TracePoint events, but that's no longer the case since
9121e57a5f.
Closesruby/ruby#6428