[pull] master from ruby:master #385

ruby/prism@62382d3967

ruby/prism@82e6f36e8f

Assertions are only enable on debug builds, so it will now check for flags of T_ZOMBIE objects on all builds in GC.verify_internal_consistency.

This adds a check in GC.verify_internal_constency that FL_FINALIZE flags is set if, and only if it is in finalizer_table.

ruby/prism@322eaea500

… specific than "any Node" * Fixes ruby/prism#2058 ruby/prism@f3e3310b5e

…ting $CHECK_FIELD_KIND ruby/prism@33e987ba3c

* To avoid duplication. ruby/prism@12e5aae0b4

ruby/prism@b7959295e9

ruby/prism@f731edcc26

`test_keyword.rb` caught this issue. Just need to run with `threshold=1`

Recent flaky canary-related CI failures have all happened while trying to fall back. It's unclear what is leaving the canary on the stack and causing gen_send_dynamic() to falsely assume that it should be leaf, and this patch isn't going to help us find the source. One source I found is Array#<< with a frozen array, but it's unclear if that's what's causing the CI failures. I'm somewhat afraid to add a canary check to rb_longjmp() since that might introduce more flaky failures, and maybe ones unrelated to YJIT. See: https://github.com/ruby/ruby/actions/runs/8083502532/job/22086714152 See: https://github.com/ruby/ruby/actions/runs/8066858522/job/22035963315

Displays for each failure which test it actually occurred in. The output destination follows the --{stdout,stderr}-on-failure option.

Before PIC era, we could assume that the stack is not unwound by imported functions since all imported functions are WASI syscalls and they don't use Asyncify at all. However, PIC binary can import functions from other modules and we cannot guarantee that they won't unwind the stack.

Use an unreleased version of RBS to see if the new commit fixes the `EBADF` error.

The finalizer could trigger a GC, so FL_FINALIZE could get out of sync with the finalizer table.

The finalizer could trigger a GC, which would cause FL_FINALIZE to be out of sync with the finalizer table.

ruby/prism@68ddf08634

This PR fixes an incorrect parsing for `Prism::Translation::Parser` when one-line pattern mathing with Ruby 2.7 runtime. ## Expected Parsing should be done based on the specified Ruby parsing version, independent of the Ruby runtime version. When parsing for Ruby 3.3, it should return `:match_pattern_p` node: ```console $ ruby -rprism -rprism/translation/parser33 -ve 'p Prism::Translation::Parser33.parse("foo in bar")' ruby 3.0.6p216 (2023-03-30 revision ruby/prism@23a532679b) [x86_64-darwin19] s(:match_pattern_p, s(:send, nil, :foo), s(:match_var, :bar)) ``` ## Actual When parsing with Ruby 2.7 runtime, `match_pattern` node is returned, even though it is expected to parse for Ruby 3.3: ```console $ ruby -rprism -rprism/translation/parser33 -ve 'p Prism::Translation::Parser33.parse("foo in bar")' ruby 2.7.8p225 (2023-03-30 revision ruby/prism@1f4d455848) [x86_64-darwin19] s(:match_pattern, s(:send, nil, :foo), s(:match_var, :bar)) ``` The cause was the use of `RUBY_VERSION` for condition logic, which made it dependent on runtime Ruby version. `Prism::Translation::Parser` supports parsing for Ruby 3.3+. Therefore, the condition for parsing Ruby 2.7, which is not supported, is being removed. ## Background Found due to incompatibility with RuboCop's `Layout/SpaceAroundKeyword` and `Style/TernaryParentheses` cops. ruby/prism@e752e251d2

If FL_FINALIZE is set but not in finalizer_table, then rb_bug.

ruby/prism@4ef4032774

ruby/prism@369ffbd57e

ruby/prism@500099e896

"AR" was well propagated to the enc.mk and mkmf, but "LD" was not. This caused the dynamic libraries to be linked with a linker found in the PATH, which could be different from the one used in the Ruby build process. This is especially important for cross-compilation, where the host linker may not be compatible with the target system. (e.g. WebAssembly)

We are going to add dynamic linking support for WASI platform. The `LDSHARED` definition is used to link shared libraries for building ruby binaries and extensions.

gc_mark_and_pin already checks for is_markable_object.

previous_insn_index() is crashing: https://github.com/ruby/ruby/actions/runs/8100712618/job/22139323673 https://github.com/ruby/ruby/actions/runs/8099334388/job/22134848249 but it's probably not the fault of previous_insn_index() itself. I'm guessing the top-most frame is a C frame, and so iseq is just 0. To confirm that, I'd like to try calling other functions on an ISEQ first.

* TruffleRuby does support C extensions but FFI is faster there. ruby/prism@d211a87691

…er#load_location * Following the changes in #2428. * PRISM_FFI_BACKEND=true ruby -v -Ilib -rprism -rbenchmark -e '10.times { p Benchmark.realtime { Dir.glob("lib/**/*.rb") { |f| Prism.parse_file(f) } } }' ruby 3.3.0: 0.255 => 0.210 ruby 3.3.0 YJIT: 0.150 => 0.120 ruby/prism@fabf809bbf

The function is only used by rb_gc_mark_machine_stack.

This patch implements handling of CAA resource records defined by [RFC8659]. - There are no known deployment of CAA records outside of IN (Internet), but the RFC does not state that CAA records are class-specific. Thus `CAA` class is defined as a class-independent RRType. - `CAA` class stores `flags` field (a 1-octet bitset) as an Integer. In this way it's easier to ensure the encoded RR is in the valid wire format. [RFC8659]: https://datatracker.ietf.org/doc/html/rfc8659 ruby/resolv@cfc4de75e3 Co-authored-by: aeris <aeris@imirhil.fr>

Bumps [actions/cache](https://github.com/actions/cache) from 4.0.0 to 4.0.1. - [Release notes](https://github.com/actions/cache/releases) - [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md) - [Commits](actions/cache@13aacd8...ab5e6d0) --- updated-dependencies: - dependency-name: actions/cache dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>

Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.24.5 to 3.24.6. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@47b3d88...8a470fd) --- updated-dependencies: - dependency-name: github/codeql-action dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>

Bumps [actions/cache](https://github.com/actions/cache) from 4.0.0 to 4.0.1. - [Release notes](https://github.com/actions/cache/releases) - [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md) - [Commits](actions/cache@13aacd8...ab5e6d0) --- updated-dependencies: - dependency-name: actions/cache dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>

ruby/optparse@77dccce37c

[Bug #20311] `rb_define_class_under` assumes it's called from C and that the reference might be held in a C global variable, so it adds the class to the VM root. In the case of `Struct.new('Name')` it's wasteful and make the struct immortal.

They are not only pinned, but also immortal. Even if the constant referencing them is removed, they will remain alive. It's a precision worth noting.

Because Travis ppc64le/s390x are unstable. ppc64le: * https://app.travis-ci.com/github/ruby/ruby/builds/269211469 * https://app.travis-ci.com/github/ruby/ruby/builds/269204073 s390x: * https://app.travis-ci.com/github/ruby/ruby/builds/269201221

…ition to send This optimizes cases such as: super(arg, *ary) super(arg, *ary, &block) super(*ary, **kw) super(*ary, kw: 1) super(*ary, kw: 1, &block) The super(*ary, **kw, &block) case does not use the splatarray false optimization. This is also true of the send case, since the introduction of the splatkw VM instruction. That will be fixed in a later commit.

This optimization stopped being using when the splatkw VM instruction was added. This change allows the optimization to apply again. This also optimizes the following cases: super(*ary, **kw, &block) f(...) super(...)

These previously resulted in 2 array allocations, one for newarray and one for concatarray. This replaces newarray and concatarray with pushtoarray, and changes splatarray false to splatarray true, which reduces it to 1 array allocation, in splatarray true. This also sets VM_CALL_ARGS_SPLAT_MUT, so if the super method accepts a positional splat, this will avoid an additional array allocation on the callee side.

These show gains from the recent optimization commits: ``` arg_splat miniruby: 7346039.9 i/s miniruby-before: 4692240.8 i/s - 1.57x slower arg_splat_block miniruby: 6539749.6 i/s miniruby-before: 4358063.6 i/s - 1.50x slower splat_kw_splat miniruby: 5433641.5 i/s miniruby-before: 3851048.6 i/s - 1.41x slower splat_kw_splat_block miniruby: 4916137.1 i/s miniruby-before: 3477090.1 i/s - 1.41x slower splat_kw_block miniruby: 2912829.5 i/s miniruby-before: 2465611.7 i/s - 1.18x slower arg_splat_post miniruby: 2195208.2 i/s miniruby-before: 1860204.3 i/s - 1.18x slower ``` zsuper only speeds up in the post argument case, because it was already set to use splatarray false in cases where there were no post arguments.

Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>

[Bug #20311] It times out on some platform, so we can reduce iterations. On my machine it completes in 250ms and RSS grows 8X.

We don't need to check that the object is pointer to the GC heap in vm_ccs_free because it is called during sweeping, which does not free pages so it can never point to an object that is not on the GC heap.

(ruby/irb#888) * Remove dead irb_level method * Restructure workspace management Currently, workspace is an attribute of IRB::Context in most use cases. But when some workspace commands are used, like `pushws` or `popws`, a workspace will be created and used along side with the original workspace attribute. This complexity is not necessary and will prevent us from expanding multi-workspace support in the future. So this commit introduces a @workspace_stack ivar to IRB::Context so IRB can have a more natural way to manage workspaces. * Fix pushws without args * Always display workspace stack after related commands are used ruby/irb@61560b99b3

While writing to the env object can add it to the remember set, it shouldn't trigger a GC run.

is_markable_object is called by rb_objspace_markable_object_p, which may pass a T_NONE object. check_rvalue_consistency will fail if a T_NONE object is passed in.

Fixes the following warning: test/irb/test_command.rb:546: warning: regular expression has ']' without escape ruby/irb@7efadc243b

In cases where a method accepts both keywords and an anonymous keyword splat, the method was not marked as taking an anonymous keyword splat. Fix that in the compiler. Doing that broke handling of nil keyword splats in yjit, so update yjit to handle that. Add a test to check that calling a method that accepts both a keyword argument and an anonymous keyword splat does not modify a passed keyword splat hash. Move the anon_kwrest check from setup_parameters_complex to ignore_keyword_hash_p, and only use it if the keyword hash is already a hash. This should speed things up slightly as it avoids a check previously used for all callers of setup_parameters_complex. Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>

Also, refactor the cfunc struct to use a new rb_cfunc_t.

cfunc.func is actually used by RJIT

The `POSTLINK` variable had been used only for darwin platforms, but it's now used for WebAssembly/WASI as well. To make shared extension libraries properly post-processed, we need to append `POSTLINK` to `LINK_SO` but it was done only for darwin platforms. This commit generalizes the appending to all platforms.

The `POSTLINK` variable had been used in the `LINK_SO` variable, which is used to link shared extension libraries. However, the `POSTLINK` variable had not been defined in the generated Makefile, so extension libraries were not properly post-processed. It was not a critical issue for the existing `POSTLINK` usage for darwin platforms, but it would be a problem for Wasm/WASI platform, which requires *mandatory* post-processing for shared extension libraries.

ruby/etc@11677318ac

The documentation for `rb_enc_interned_str_cstr` notes that `enc` can be a null pointer, but this currently causes a segmentation fault when trying to autoload the encoding. This commit fixes the issue by checking for NULL before calling `rb_enc_autoload`.

This is a follow up change to 71d5116

This change makes `make_encmake.rb` expand all substitution variables when replacing them in `enc/Makefile.in` to avoid propagating all possibly referenced variables to the generated Makefile. The old behavior, which don't expand make variables when generating Makefile, was useful to temporarily override inherited variables like `cflags` in `CFLAGS` at make-time. However, it's not a common use case and it requires to propagate all possibly referenced variables properly considering key name duplication between `enc/Makefile.in` and `RbConfig::CONFIG`.

callcc's implementation is fundamentally incompatible with ASAN. Since callcc is deprecated and almost never used, it's probably OK to disable callcc when ruby is compiled with ASAN. [Bug #20273]

The `RUBY_CODESIGN` environment variable is used by mkmf-generated Makefile to sign extension bundles on macOS. The variable specifies a key identifier to use for signing given by the user. However, the key is usually stored in `$HOME/Library/Keychains` directory, and the test suite creates a fake `$HOME` directory. This causes the test suite to try to find the specified key from the fake home directory, which results in a failure. rubygems/rubygems@ddcfc65bf7

ruby/prism@c6c771d1fa

ruby/prism@1fe507fe3d

…slation::Parser` This PR fixes the following incompatibility AST for regexp match between Parser gem and Prism: ## Parser gem Returns an `match_with_lvasgn` node: ```console $ bundle exec ruby -rparser/ruby33 -ve 'p Parser::Ruby33.parse("/foo/ =~ bar")' ruby 3.3.0 (2023-12-25 revision ruby/prism@5124f9ac75) [x86_64-darwin22] s(:match_with_lvasgn, s(:regexp, s(:str, "foo"), s(:regopt)), s(:send, nil, :bar)) ``` ## Prism (`Prism::Translation::Parser`) ### Before Returns an `send` node: ```console $ bundle exec ruby -rprism -rprism/translation/parser33 -ve 'p Prism::Translation::Parser33.parse("/foo/ =~ bar")' ruby 3.3.0 (2023-12-25 revision ruby/prism@5124f9ac75) [x86_64-darwin22] s(:send, s(:regexp, s(:str, "foo"), s(:regopt)), :=~, s(:send, nil, :bar)) ``` ### After Returns an `match_with_lvasgn` node: ```console $ bundle exec ruby -rprism -rprism/translation/parser33 -ve 'p Prism::Translation::Parser33.parse("/foo/ =~ bar")' ruby 3.3.0 (2023-12-25 revision ruby/prism@5124f9ac75) [x86_64-darwin22] s(:match_with_lvasgn, s(:regexp, s(:str, "foo"), s(:regopt)), s(:send, nil, :bar)) ``` ## Background Found due to incompatibility with RuboCop's `Performance/EndWith`, `Performance/StringInclude, and `Performance/StartWith` cops. ## Note This is the incompatibility when the receiver is a regular expression literal and `=~` is used. Based on the node name `:match_with_lvasgn`, it appears that Prism's AST becomes more accurate in cases like `visit_match_write_node` only. However, as shown in the background, the current behavior of Parser gem is not like this. Considering compatibility with the published AST of Parser gem, the AST incompatibility will be addressed. This lvar-injecting feature appears to have not been supported by Parser gem for a long time: whitequark/parser#69 (comment) There seems to be no indication that it will be supported. This PR prioritizes AST compatibility between the Parser gem and Prism. However, it is unclear whether this is the best approach. ruby/prism@dff4abb170

ruby/prism@dccfd83bc4

Previous documentation is stating the opposite (that the method won't work for CRuby).

- Add `x` prefix to malloc, calloc, realloc, and free (eg: malloc -> xmalloc) - By default, they are replaced with stdlib's functions at build - You can use custom functions by defining `PRISM_CUSTOM_ALLOCATOR` macro ruby/prism@7a878af619

- PRISM_CUSTOM_ALLOCATOR -> PRISM_XALLOCATOR - prism_custom_allocator.h -> prism_xallocator.h ruby/prism@83b4071e5b

…in branch ruby/prism@08733438bd

ruby/prism@ee1a4acacd

ruby/prism@e1e613df16

@ivar

* The stdlib StringIO is synchronized and this occurs a high overhead. * This is about twice as fast on TruffleRuby but surprisingly it is slower on JRuby. I am not sure why but probably @ivar access and integer arithmetic is much slower than Java field access/arithmetic on JRuby. * On CRuby interpreter it is slower, which is expected as the GVL already protects StringIO. * So we enable this only on TruffleRuby to not slow down other Rubies. * PRISM_FFI_BACKEND=true ruby -v -Ilib -rprism -rbenchmark -e '300.times { p Benchmark.realtime { Dir.glob("lib/**/*.rb") { |f| Prism.parse_file(f) } } }' ruby 3.3.0: 0.215 => 0.251 (cext: 0.062) ruby 3.3.0 YJIT: 0.118 => 0.113 (cext: 0.053) truffleruby JVM: 0.101 => 0.054 jruby 9.4.6.0: 0.162 => 0.219 jruby 9.4.6.0 indy: 0.078 => 0.086 * For the record here are the numbers for using the String directly, without a StringIO-like object: ruby 3.3.0: 0.215 => 0.234 (cext: 0.062) ruby 3.3.0 YJIT: 0.118 => 0.111 (cext: 0.053) truffleruby native: 0.101 => 0.053 jruby 9.4.6.0: 0.162 => 0.195 jruby 9.4.6.0 indy: 0.078 => 0.082 As we can see, that extra object adds a non-trivial overhead on CRuby interpreter and JRuby. But we need to make it possible to use StringIO and SimpleStringIO interchangeably. ruby/prism@938677cbd2

ruby/prism@919d682379

Fixes [Bug #19975]

ruby/prism@d0dbf01bef

ruby/prism@acdff3aae3

ruby/prism@537947aa5c

Bumps [rb-sys](https://github.com/oxidize-rb/rb-sys) from 0.9.89 to 0.9.90. - [Release notes](https://github.com/oxidize-rb/rb-sys/releases) - [Commits](oxidize-rb/rb-sys@v0.9.89...v0.9.90) --- updated-dependencies: - dependency-name: rb-sys dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> rubygems/rubygems@eb93d8b238

…file" This reverts commit 71d5116.

- Redirect stderr `git ls-files` to null without shelling out. - When building by `gem`, `__FILE__` is the path name given in the command line, or the gemspec file name in the current directory. In that case, comparison it and expanded path never equal. Compare listed file names with the base name of `__FILE__` instead. rubygems/rubygems@5583433dbb

On macOS, `dsymutil` utility splits debug info into .dSYM directory. Glob list of `.bundle/cache/extensions/**/*binary_c*` includes that directory but `FileUtils.rm` fails to unlink a directory. https://github.com/ruby/ruby/actions/runs/8149918901/job/22275331688#step:11:3000 ``` Operation not permitted @ apply2files - /Users/runner/work/ruby/ruby/src/tmp/2/home/.bundle/cache/extensions/arm64-darwin-22/ruby/3.4.0+0/3b02a1011c53518f911ab3a9e8c6c608/very_simple_binary-1.0/very_simple_binary_c.bundle.dSYM # ./lib/fileutils.rb:2332:in 'File.unlink' # ./lib/fileutils.rb:2332:in 'block in FileUtils::Entry_#remove_file' # ./lib/fileutils.rb:2337:in 'FileUtils::Entry_#platform_support' # ./lib/fileutils.rb:2331:in 'FileUtils::Entry_#remove_file' # ./lib/fileutils.rb:1475:in 'FileUtils.remove_file' # ./lib/fileutils.rb:1223:in 'block in FileUtils.rm' # ./lib/fileutils.rb:1222:in 'FileUtils.rm' # ./spec/bundler/install/global_cache_spec.rb:235:in 'block (3 levels) in <top (required)>' ``` rubygems/rubygems@375c127684

…efile" This reverts commit 0ae0a0c.

Signed-off-by: cui fliter <imcusg@gmail.com>

(ruby/irb#859) This allows hierarchy when loading rc files for example both files below are loaded; project/.irbrc ~/.irbrc ruby/irb@b53ebc6655 Co-authored-by: Stan Lo <stan001212@gmail.com>

It's to avoid the failures by the infra issues in the term of the following maintenance. There is a planned maintenance on March 6th 2024 between 8:00 and 12:00 UTC+0. The Travis service may be temporarily unavailable. https://bugs.ruby-lang.org/issues/20013#note-28

irb will load multiple rc files now. If developer have their rcfile on home directory or etc, equal assertion will fail with custom prompt.

(ruby/irb#893) Some cases of it currently create `~/.irb_history` files unintentionally while others don't. This is caused by the varying levels of setup/cleanup between them. This commit fixes the issue by wrapping every single test inside a consistent test setup and teardown callbacks. ruby/irb@a2a3cbb0ef

Remove `struct rb_io {...}`.

(ruby/irb#894) ruby/irb@dc0dd25a39

Recent `codesign` seems to emit a "replacing existing signature" warning even if it was an adhoc signature added by the linker. Since "adhoc" signatures do not cause a failure when replaced, it is just unnecessary and noisy.

…rily." This reverts commit 23dc7aa. It seems that the planned maintenance was finished. https://bugs.ruby-lang.org/issues/20013#note-28

ruby/time@4abeaec776

Prism has been directly supported as a parser engine since RuboCop 1.62: https://github.com/rubocop/rubocop/releases/tag/v1.62.0 This makes specifying `TargetRubyVersion` with special values like `80_82_73_83_77.33` using the `prism/translation/parser/rubocop` file unnecessary. As a result, it would be possible to deprecate this approach. OTOH, early users might be surprised if `prism/translation/parser/rubocop` were to be suddenly removed. Therefore, this PR deprecates the parameters related to `prism/translation/parser/rubocop`. ```console $ bundle exec ruby -rrubocop -rprism/translation/parser/rubocop -e "RuboCop::AST::ProcessedSource.new('42', 80_82_73_83_77.33).ast" WARN: Prism is directly supported since RuboCop 1.62. The `prism/translation/parser/rubocop` file is deprecated. WARN: Setting `TargetRubyVersion: 80_82_73_83_77.33` is deprecated. Set to `ParserEngine: parser_prism` and `TargetRubyVersion: 3.3` instead. $ bundle exec ruby -rrubocop -rprism/translation/parser/rubocop -e "RuboCop::AST::ProcessedSource.new('42', 80_82_73_83_77.34).ast" WARN: Prism is directly supported since RuboCop 1.62. The `prism/translation/parser/rubocop` file is deprecated. WARN: Setting `TargetRubyVersion: 80_82_73_83_77.34` is deprecated. Set to `ParserEngine: parser_prism` and `TargetRubyVersion: 3.4` instead. ``` Eventually, it will be possible to remove it at some point. Regarding documentation, it has been updated to not show the old, discouraged usage but rather the new way of specifying it in RuboCop. ruby/prism@0e4bc31463

ruby/prism@7a277be5fb

ruby/prism@4ba9abf664

ruby/prism@b9d762c76a

ruby/prism@88b8185075

ruby/prism@b6927ac714

ruby/prism@336bd7249a

ruby/prism@9a883a474a

ruby/prism@57f991a6a6

ruby/prism@4e64b9fc53

ruby/prism@b2dc35d902

…tion ruby/prism@129ed94cb5

ruby/prism@93d06436f7

ruby/prism@107ffb64a3

ruby/prism@e6e17778f8

ruby/prism@dfa499d2e9

ruby/prism@6285e31ccc

ruby/prism@788cf7c528

ruby/prism@57c1dd4859

ruby/prism@a3c8c27c20

ruby/prism@5e47d8eb67

ruby/prism@7f5a09f40e

ruby/prism@ef9dca2a4c

ruby/prism@6611820b7b

ruby/prism@2d635ce46b

ruby/prism@c5c8299485

ruby/prism@602d3d2ccb

ruby/prism@ceb5a5cf62

ruby/prism@6bd7ae2ed2

ruby/prism@3fd962f2d3

ruby/prism@a76744be47

ruby/prism@18dea6ce64

ruby/prism@356c97c736

ruby/prism@d31cf63d45

ruby/prism@372200f970

ruby/prism@90f8b33fad

ruby/prism@149d01f2c9

ruby/prism@9dbad71aa3

ruby/prism@8feb073fe4

ruby/prism@b7cd5c8e74

ruby/prism@a3156e60cc

ruby/prism@a5c3d634ef

ruby/prism@c00902af23

ruby/prism@4344b70ed5

ruby/prism@798517da1a

ruby/prism@22b9f3ccd9

ruby/prism@836adb0aaa

ruby/prism@3c28994a24

ruby/prism@8b14a85a4c

ruby/prism@87538f1a12

ruby/prism@8fa476d9a1

ruby/prism@41c84df423

ruby/prism@4d08736bd5

ruby/prism@de9e55dd43

ruby/prism@f4f7f8fc87

ruby/prism@27a427bc22

ruby/prism@9c298f294d

…ranslation ruby/prism@117c7418af

…ation ruby/prism@36bae94f06

ruby/prism@1f16df1f9e

ruby/prism@81feef447a

ruby/prism@6088ca1152

…ranslation ruby/prism@64e8190da0

ruby/prism@06a89c3540

…tion ruby/prism@f315bdb45d

ruby/prism@4639803277

…ation ruby/prism@fe10b5f49f

…ation ruby/prism@972fe60aea

…lation ruby/prism@4e7733491f

ruby/prism@dc74428e2e

ruby/prism@cf21c08c0b

ruby/prism@8331874218

…ranslation ruby/prism@240bb08c2c

ruby/prism@6019342278

ruby/prism@99eca8b1d2

ruby/prism@e0a836ebc2

ruby/prism@37db4d8c2d

ruby/prism@a35eadce47

ruby/prism@b607e3a98d

…pper translation ruby/prism@1729e8aec0

ruby/prism@0c008fcf34

ruby/prism@76cf29e68d

…ation ruby/prism@36a0b2e45a

ruby/prism@3f59d07388

ruby/prism@a66d066162

ruby/prism@716ee0e91a

ruby/prism@7f7840d318

…nslation ruby/prism@97a031e1d3

ruby/prism@5030917eb0

…tion ruby/prism@e23eae8266

ruby/prism@f8b973e8cd

ruby/prism@5cf5f15ee7

This fixes test failures when running tests with RUBY_ISEQ_DUMP_DEBUG=to_binary, which started after 5899f6a was committed. Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>

ruby/prism@62d4376a53

This frees FL_USER0 on both T_MODULE and T_CLASS. Note: prior to this, FL_SINGLETON was never set on T_MODULE, so checking for `FL_SINGLETON` without first checking that `FL_TYPE` was `T_CLASS` was valid. That's no longer the case.

This `st_table` is used to both mark and pin classes defined from the C API. But `vm->mark_object_ary` already does both much more efficiently. Currently a Ruby process starts with 252 rooted classes, which uses `7224B` in an `st_table` or `2016B` in an `RArray`. So a baseline of 5kB saved, but since `mark_object_ary` is preallocated with `1024` slots but only use `405` of them, it's a net `7kB` save. `vm->mark_object_ary` is also being refactored. Prior to this changes, `mark_object_ary` was a regular `RArray`, but since this allows for references to be moved, it was marked a second time from `rb_vm_mark()` to pin these objects. This has the detrimental effect of marking these references on every minors even though it's a mostly append only list. But using a custom TypedData we can save from having to mark all the references on minor GC runs. Addtionally, immediate values are now ignored and not appended to `vm->mark_object_ary` as it's just wasted space.

* WIP getbyte implementation * WIP String#getbyte implementation * Fix whitespace in stats.rs * fix? * Fix whitespace, add comment --------- Co-authored-by: Aaron Patterson <aaron.patterson@shopify.com>