I think this change fixes the following assertion failure:
```
[BUG] unexpected rb_parser_ary_data_type (2114076960) for script lines
```
It seems that `ast_value` is collected then `rb_parser_build_script_lines_from`
touches invalid memory address.
This change prevents `ast_value` from being collected by RB_GC_GUARD.
Many functions take an outlined code block but do nothing more than
passing it along; only a couple of functions actually make use of it.
So, in most cases the `ocb` parameter is just boilerplate.
Most functions that take `ocb` already also take a `JITState` and this
commit moves `ocb` into `JITState` to remove the visual noise of the
`ocb` parameter.
* Set VM_CALL_KWARG flag first and reuse it to avoid checking kw_arg twice
* Fix comment for VM_CALL_ARGS_SIMPLE
* Make VM_CALL_ARGS_SIMPLE set-site match its comment
Instead, build it during setup when in CI.
This should avoid some Windows specific test failures when Bundler
copies the same files from multiple processes and runs into EACESS
errors.
https://github.com/rubygems/rubygems/commit/c194a1d753
[Bug #20598]
Just like [Bug #20595], Encoding#name_list and Encoding#aliases can have
their strings corrupted when Encoding.default_internal is set to nil.
Co-authored-by: Matthew Valentine-House <matt@eightbitraptor.com>
[Bug #20595]
enc_set_default_encoding will free the C string if the encoding is nil,
but the C string can be used by the encoding name string. This will cause
the encoding name string to be corrupted.
Consider the following code:
Encoding.default_internal = Encoding::ASCII_8BIT
names = Encoding.default_internal.names
p names
Encoding.default_internal = nil
p names
It outputs:
["ASCII-8BIT", "BINARY", "internal"]
["ASCII-8BIT", "BINARY", "\x00\x00\x00\x00\x00\x00\x00\x00"]
Co-authored-by: Matthew Valentine-House <matt@eightbitraptor.com>
This commit fixes splat and block handling when calling in to a
forwarding iseq. In the case of a splat we need to avoid expanding the
array to the stack. We need to also ensure the CI write is flushed to
the SP, otherwise it's possible for a block handler to clobber the CI
[ruby-core:118360]
We face `[BUG] unexpected rb_parser_ary_data_type (0) for script lines`
on master branch recently.
This commit changes `enum rb_parser_ary_data_type` to start with `1`
and `0` to be invalid then it makes clear `rb_parser_ary_data_type (0)`
is not intentional.
Fix warning
```
/******************************************************************************/
^
warning: [dangling-doc-comments] documentation comment is not attached to any declaration
```
in Nodes.java and AbstractNodeVisitor.java files. /** is treated as a starting of a javadoc comment.
https://github.com/ruby/prism/commit/c83d7844b8
This commit switches out the full gemspec validation for a partial one
which only performs resolution related checks. This will allow gem
authors to run `bundle` commands immediately after creating a new gem
with Bundler, rather than having to fix metadata validation issues in
the default gemspec.
https://github.com/rubygems/rubygems/commit/d5aa9cae9d
This method validates only what is required for resolution, skipping any
irrelevant metadata validation. This will be used by Bundler instead of
doing a full validation, allowing gem authors to use `bundle` commands
immediately in newly created gems without first having to fix invalid
metafata fields in the default gemspec.
https://github.com/rubygems/rubygems/commit/da7704cfc0
