- ruby-core - ml.ruby-lang.org

[ruby-core:121772] [Ruby Bug#21294] URI.extract is extracting invalid URIs with a mishmash of IPv6 notation with IPv4 address
by Keeyan (Keeyan Nejad) 30 Apr '25

30 Apr '25

Issue #21294 has been reported by Keeyan (Keeyan Nejad). ---------------------------------------- Bug #21294: URI.extract is extracting invalid URIs with a mishmash of IPv6 notation with IPv4 address https://bugs.ruby-lang.org/issues/21294 * Author: Keeyan (Keeyan Nejad) * Status: Open * ruby -v: ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following is not a valid URI: `http://[127.0.0.1]`. So `URI.extract` should not extract it. It seems it is extracting it, though. So if you have code which extracts all URIs and then parses them, like the following, an error will be raised: ``` ruby require 'uri' URI.extract("Fake URL: http://[127.0.0.1]" , :http).each do |uri| # => ['http://[127.0.0.1]'] URI.parse(uri) # => raise URI::InvalidURIError end ``` ``` /home/keeyan/.local/share/mise/installs/ruby/3.4.3/lib/ruby/3.4.0/uri/rfc3986_parser.rb:130:in 'URI::RFC3986_Parser#split': bad URI (is not URI?): "http://[127.0.0.1]" (URI::InvalidURIError) from /home/keeyan/.local/share/mise/installs/ruby/3.4.3/lib/ruby/3.4.0/uri/rfc3986_parser.rb:135:in 'URI::RFC3986_Parser#parse' from /home/keeyan/.local/share/mise/installs/ruby/3.4.3/lib/ruby/3.4.0/uri/common.rb:212:in 'URI.parse' from test.rb:4:in 'block in <main>' from test.rb:3:in 'Array#each' from test.rb:3:in '<main>' ``` Instead, I believe `URI.extract`, should return an empty array. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121762] [Ruby Bug#21292] wrong number of arguments (given 2, expected 0) (ArgumentError) since 8ac8225c504dee57454131e7cde2c47126596fdc
by yahonda (Yasuo Honda) 29 Apr '25

29 Apr '25

Issue #21292 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #21292: wrong number of arguments (given 2, expected 0) (ArgumentError) since 8ac8225c504dee57454131e7cde2c47126596fdc https://bugs.ruby-lang.org/issues/21292 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 3.5.0dev (2025-04-25T20:46:05Z master 8ac8225c50) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Rails CI against Ruby master branch has been failing https://buildkite.com/rails/rails-nightly/builds/2129#019673e6-eed1-4ce3-94… According to git bisect, this behavior change has been introduced via 8ac8225c504dee57454131e7cde2c47126596fdc and I think I have managed to reproduce it. ### Steps to reproduce 1. Create foo.rb ```ruby class Foo def initialize @foo = nil end class << self private def method_missing(method_name, ...) Bar.new(self, method_name, ...) end # Workaround for Ruby 3.5.0 # def method_missing(method_name, *args, &block) # Bar.new(self, method_name, *args, &block) # end end end class Bar def initialize(class_name, action, *args) @class_name = class_name @action = action @args = args end end p RUBY_VERSION foo = Foo.hello p foo ``` 2. Run this foo.rb ``` $ ruby foo.rb ``` ### Expected behavior It should show the Ruby version and local variable foo as Ruby 3.4.3 does ```ruby $ ruby -v ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x86_64-linux] $ ruby foo.rb "3.4.3" #<Bar:0x00007f130ed47bc8 @class_name=Foo, @action=:hello, @args=[]> $ ``` ### Actual behavior It raises the wrong number of arguments (given 2, expected 0) (ArgumentError) ```ruby $ ruby -v ruby 3.5.0dev (2025-04-25T20:46:05Z master 8ac8225c50) +PRISM [x86_64-linux] $ ruby foo.rb "3.5.0" foo.rb:2:in 'initialize': wrong number of arguments (given 2, expected 0) (ArgumentError) from foo.rb:10:in 'Foo.method_missing' from foo.rb:29:in '<main>' $ ``` ### Additional information 1. To workaround this error, update the method_missing signature as follows. ``` def method_missing(method_name, *args, &block) Bar.new(self, method_name, *args, &block) end ```` 2. This does not reproduce against e0545a0250 that is the parent commit of 8ac8225 ```ruby $ ruby -v ruby 3.5.0dev (2025-04-25T18:04:45Z master e0545a0250) +PRISM [x86_64-linux] $ ruby foo.rb "3.5.0" #<Bar:0x00007f3ac640f8a0 @class_name=Foo, @action=:hello, @args=[]> $ ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:121757] [Ruby Bug#21291] possible bug with /m regexp and $ based on input
by zenspider (Ryan Davis) 29 Apr '25

29 Apr '25

Issue #21291 has been reported by zenspider (Ryan Davis). ---------------------------------------- Bug #21291: possible bug with /m regexp and $ based on input https://bugs.ruby-lang.org/issues/21291 * Author: zenspider (Ryan Davis) * Status: Open * ruby -v: 3.4.2 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- reported in discord by the.unnamed user: ``` ruby #!/usr/bin/env -S ruby -vw # => ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] p "a\n" =~ /$./m # => 1 p "a\n" =~ /$.*/m # => 1 p "aa\n" =~ /$./m # => 2 p "aa\n" =~ /$.*/m # !!! # => nil p "aa\n" =~ /$[\S\s]*/m # => 2 ``` goes back to at least 3.2.8 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:121747] [Ruby Bug#21288] StringScanner#named_captures overrides matched captures with unmatched captures
by robotdana (Dana Sherson) 28 Apr '25

28 Apr '25

Issue #21288 has been reported by robotdana (Dana Sherson). ---------------------------------------- Bug #21288: StringScanner#named_captures overrides matched captures with unmatched captures https://bugs.ruby-lang.org/issues/21288 * Author: robotdana (Dana Sherson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- StringScanner#named_captures operates inconsistently with Regexp#named_captures when there is the same name used in multiple branches For Regexp it uses the value that was captured (useful). For StringScanner it uses the one last in source order. ```ruby require 'strscan' re = /(?<test>value)|(?<test>other branch)/ scanner = StringScanner.new("value") scanner.scan(re) scanner.named_captures #=> {"test" => nil} "value".match(re).named_captures # => {"test" => "test"} scanner = StringScanner.new('other branch') scanner.scan(re) scanner.named_captures #=> {"test" => "other branch"} "other branch".match(re).named_captures # => {"test" => "other branch"} ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:116370] [Ruby master Bug#20203] `TestEnumerable` test failures with GCC 14
by vo.x (Vit Ondruch) 28 Apr '25

28 Apr '25

Issue #20203 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20203: `TestEnumerable` test failures with GCC 14 https://bugs.ruby-lang.org/issues/20203 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- There is ongoing mass rebuild in Fedora and that is first time GCC 14 is used and we observe test failures in `TestEnumerable`. Here are a few examples: ~~~ [ 3000/26419] TestEnumerable#test_transient_heap_sort_bymalloc_consolidate(): unaligned fastbin chunk detected ~~~ ~~~ [ 2455/26535] TestEnumerable#test_transient_heap_sort_bycorrupted size vs. prev_size in fastbins ~~~ ~~~ [ 9716/26532] TestEnumerable#test_any_with_unused_blockdouble free or corruption (fasttop) ~~~ The full logs are accessible [here](https://koji.fedoraproject.org/koji/taskinfo?taskID=112176941). Please drill through `Descendants` and `build.log` -- https://bugs.ruby-lang.org/

5 12

[ruby-core:121680] [Ruby Bug#21271] Ruby build failure due to invalid probe specifier for dtrace
by nekketsuuu (Takuma Ishikawa) 27 Apr '25

27 Apr '25

Issue #21271 has been reported by nekketsuuu (Takuma Ishikawa). ---------------------------------------- Bug #21271: Ruby build failure due to invalid probe specifier for dtrace https://bugs.ruby-lang.org/issues/21271 * Author: nekketsuuu (Takuma Ishikawa) * Status: Open * ruby -v: N/A * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I've noticed that building the master branch of Ruby fails on my MacBook with the following error about dtrace and probes.h: ``` % make BASERUBY = /Users/nekketsuuu/.rbenv/shims/ruby --disable=gems CC = clang LD = ld LDSHARED = clang -dynamiclib CFLAGS = -isystem/opt/homebrew/include -isystem/opt/homebrew/include -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wextra-tokens -Wdeprecated-declarations -Wdivision-by-zero -Wdiv-by-zero -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wshorten-64-to-32 -Wwrite-strings -Wold-style-definition -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wunused-variable -Wmisleading-indentation -Wundef -pipe -arch arm64 XCFLAGS = -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -fPIE -I. -I.ext/include/arm64-darwin24 -I../include -I.. -I../prism -I../enc/unicode/15.0.0 -Dmodular_gc_dir= CPPFLAGS = -I/opt/homebrew/opt/openssl/include -I/opt/homebrew/opt/mysql-client(a)8.4/include -I/opt/homebrew/opt/libffi/include -isystem/opt/homebrew/include -I/opt/homebrew/opt/openssl/include -I/opt/homebrew/opt/mysql-client(a)8.4/include -I/opt/homebrew/opt/libffi/include -isystem/opt/homebrew/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT DLDFLAGS = -L/opt/homebrew/opt/openssl/lib -L/opt/homebrew/opt/mysql-client(a)8.4/lib -L/opt/homebrew/opt/libffi/lib -L/opt/homebrew/lib -L/opt/homebrew/opt/openssl/lib -L/opt/homebrew/opt/mysql-client(a)8.4/lib -L/opt/homebrew/opt/libffi/lib -L/opt/homebrew/lib -Wl,-undefined,dynamic_lookup -fstack-protector-strong -Wl,-pie -framework CoreFoundation -arch arm64 SOLIBS = -lgmp -ldl -lobjc -lpthread LANG = ja_JP.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = RUSTC = rustc YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --edition=2021 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/Users/nekketsuuu/dev/src/github.com/ruby/ruby/build/yjit/target/release/' ../yjit/src/lib.rs Apple clang version 16.0.0 (clang-1600.0.26.3) Target: arm64-apple-darwin24.4.0 Thread model: posix InstalledDir: /Applications/Xcode_16.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin compiling ../main.c compiling ../dmydln.c generating id.h id.h updated generating miniprelude.c miniprelude.c updated compiling ../miniinit.c making ../array.rbinc /Users/nekketsuuu/.rbenv/shims/ruby --disable=gems ../tool/gen_dummy_probes.rb ../probes.d > probes.dmyh translating probes ../probes.d dtrace: invalid probe specifier system/opt/homebrew/include: syntax error near end of input make: *** [probes.h] Error 1 ``` With running `git bisect`, I found that the build started failing after the commit 060ae17c806f0ba955b1c5d825b890b6de6c47e3 https://github.com/ruby/ruby/commit/060ae17c806f0ba955b1c5d825b890b6de6c47e3 (between Ruby 3.4.3 d0b7e5b6a04bde21ca483d20a1546b28b401c2d4 and the HEAD 7e2ba5a91bcdc31e14502f797a6184e3f4d41747). I'm not sure if this is a problem of my local configurations or a build script. Here is a summary of my configurations: ``` Configuration summary for ruby version 3.5.0 * Installation prefix: /Users/nekketsuuu/.rbenv/versions/master * exec prefix: ${prefix} * arch: arm64-darwin24 * site arch: ${arch} * RUBY_BASE_NAME: ruby * ruby lib prefix: ${libdir}/${RUBY_BASE_NAME} * site libraries path: ${rubylibprefix}/${sitearch} * vendor path: ${rubylibprefix}/vendor_ruby * target OS: darwin24 * compiler: clang * with thread: pthread * with coroutine: arm64 * with modular GC: no * enable shared libs: no * dynamic library ext: bundle * CFLAGS: ${hardenflags} -fdeclspec ${optflags} \ ${debugflags} ${warnflags} * LDFLAGS: -L. -L/opt/homebrew/opt/openssl/lib \ -L/opt/homebrew/opt/mysql-client(a)8.4/lib \ -L/opt/homebrew/opt/libffi/lib \ -L/opt/homebrew/lib \ -L/opt/homebrew/opt/openssl/lib \ -L/opt/homebrew/opt/mysql-client(a)8.4/lib \ -L/opt/homebrew/opt/libffi/lib \ -L/opt/homebrew/lib -fstack-protector-strong * DLDFLAGS: -L/opt/homebrew/opt/openssl/lib \ -L/opt/homebrew/opt/mysql-client(a)8.4/lib \ -L/opt/homebrew/opt/libffi/lib \ -L/opt/homebrew/lib \ -L/opt/homebrew/opt/openssl/lib \ -L/opt/homebrew/opt/mysql-client(a)8.4/lib \ -L/opt/homebrew/opt/libffi/lib \ -L/opt/homebrew/lib -Wl,-undefined,dynamic_lookup * optflags: -O3 -fno-fast-math * debugflags: -ggdb3 * warnflags: -Wall -Wextra -Wextra-tokens \ -Wdeprecated-declarations -Wdivision-by-zero \ -Wdiv-by-zero -Wimplicit-function-declaration \ -Wimplicit-int -Wpointer-arith -Wshorten-64-to-32 \ -Wwrite-strings -Wold-style-definition \ -Wmissing-noreturn -Wno-cast-function-type \ -Wno-constant-logical-operand -Wno-long-long \ -Wno-missing-field-initializers \ -Wno-overlength-strings -Wno-parentheses-equality \ -Wno-self-assign -Wno-tautological-compare \ -Wno-unused-parameter -Wno-unused-value \ -Wunused-variable -Wmisleading-indentation -Wundef * hardenflags: -fstack-protector-strong -U_FORTIFY_SOURCE \ -D_FORTIFY_SOURCE=2 * strip command: strip -A -n * install doc: rdoc * YJIT support: yes * RJIT support: yes * man page type: doc * BASERUBY -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) \ +PRISM [arm64-darwin24] ``` and here is a full command logs by `make Q=`: ``` translating probes ../probes.d dtrace -xnolibs -o probes.h.tmp -h -C -I. -I.ext/include/arm64-darwin24 -I../include -I.. -I../prism -I../enc/unicode/15.0.0 -I/opt/homebrew/opt/openssl/include -I/opt/homebrew/opt/mysql-client(a)8.4/include -I/opt/homebrew/opt/libffi/include -isystem/opt/homebrew/include -I/opt/homebrew/opt/openssl/include -I/opt/homebrew/opt/mysql-client(a)8.4/include -I/opt/homebrew/opt/libffi/include -isystem/opt/homebrew/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT -s ../probes.d dtrace: invalid probe specifier system/opt/homebrew/include: syntax error near end of input make: *** [probes.h] Error 1 ``` It appears that CPPFLAGS contains `-isystem` flag, and dtrace might handle it as `-i` flag. This is my first time submitting a bug issue here. Feel free to correct me if there are any mistakes. Also, let me know if more information is needed. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:121627] [Ruby Feature#21264] Extract Date library from Ruby repo in the future
by hsbt (Hiroshi SHIBATA) 26 Apr '25

26 Apr '25

Issue #21264 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- Note: This is not for Ruby 3.5. `Date` and `DateTime` has no primary maintainer in 10+ years. I would like to deprecate `date` via bundled gems for reducing our maintenance time especially @nobu. But `Time.prase` and `Time.strptime` are widely used now. How do we deprecate `date` library? 1. Migrate `Date._strptime`, `Date.strptime` and `Date._parse` to `Time`. The current `Date` is migrated as bundled gems. 2. Migrate `Date` to the bundled gems. `Time.parse` and `Time.strptime` warns if `date` is not found. 3. Keep the current situation 4. ... Does anyone have another idea? -- https://bugs.ruby-lang.org/

4 7

[ruby-core:121683] [Ruby Bug#21272] Class.new doesn't trigger :class TracePoint
by st0012 (Stan Lo) 26 Apr '25

26 Apr '25

Issue #21272 has been reported by st0012 (Stan Lo). ---------------------------------------- Bug #21272: Class.new doesn't trigger :class TracePoint https://bugs.ruby-lang.org/issues/21272 * Author: st0012 (Stan Lo) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- According to the official [documentation](https://docs.ruby-lang.org/en/master/TracePoint.html#class-T…: > To filter what is traced, you can pass any of the following as events: > > :class > Start a class or module definition. I'd expect `:class` events to be triggered when new classes are defined via `Class.new` as well, but currently that's not the case. Should we either support `Class.new`, or clarify the behaviour in documentation? ### Reproduction ```rb TracePoint.trace(:class) do |tp| puts "Class created at line: #{tp.lineno}" end class Foo; end # Triggers the tracepoint Baz = Class.new # Doesn't trigger the tracepoint # ruby test.rb # Class created at line: 5 ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:121731] [Ruby Bug#21285] Range#overlap? returns false for (nil..nil)
by andrykonchin (Andrew Konchin) 26 Apr '25

26 Apr '25

Issue #21285 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21285: Range#overlap? returns false for (nil..nil) https://bugs.ruby-lang.org/issues/21285 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.4.3 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I've notices the following edge case: ```ruby (..1).overlap?(nil..nil) => false ``` But I expect `true` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121560] [Ruby Feature#21221] Proposal to upstream ZJIT
by maximecb (Maxime Chevalier-Boisvert) 25 Apr '25

25 Apr '25

Issue #21221 has been reported by maximecb (Maxime Chevalier-Boisvert). ---------------------------------------- Feature #21221: Proposal to upstream ZJIT https://bugs.ruby-lang.org/issues/21221 * Author: maximecb (Maxime Chevalier-Boisvert) * Status: Open * Assignee: maximecb (Maxime Chevalier-Boisvert) * Target version: 3.5 ---------------------------------------- # Background For the past 3 months, the YJIT team at Shopify has been working on a next-generation Ruby JIT, which we refer to as ZJIT. This new compiler is currently being developed in a private fork, with the hope that we can eventually upstream it into ruby/ruby. Maxime Chevalier-Boisvert will give a talk at RubyKaigi 2025 to officially announce the project to the Ruby community and the broader public. # Design of ZJIT YJIT compiles YARV bytecode more or less directly to machine code. This has the benefit that YJIT compiles code fast and that it’s a relatively simple architecture, which was helpful in building the compiler incrementally. The downside is that YJIT is difficult to extend and build upon. In particular, YJIT is very limited when it comes to optimizations that cross YARV instruction boundaries. We’ve known for some time that in order to unlock higher levels of performance, a Ruby JIT would need the ability to perform more aggressive inlining, but it is challenging to cleanly do this in YJIT. The main innovation of ZJIT is that it has its own Static Single Assignment (SSA) Intermediate Representation (IR). YARV bytecode is converted into this IR, which can then be optimized using multiple optimization passes. These passes can be orthogonal and modular to some degree, which makes the design of the compiler easier to reason about, easier to extend and also opens up the possibility of having multiple JIT compilation tiers in the future, which is something that both Matz and Takashi Kokubun have hoped to see in a Ruby JIT for some time. In addition to this, we are moving to a more traditional method-based JIT compiler design. I (Maxime) have had the chance to help build and deploy Lazy Basic Block Versioning (LBBV), an offshoot of my PhD research into a production compiler, an opportunity which I’m very thankful for. However, I feel like ZJIT might benefit from having a compiler architecture that is more “standard”. With YJIT, we’ve had very few contributions from Ruby Core contributors outside of Shopify. I’m hoping that if we build a compiler with an architecture that is more textbook-like, we could have a project that is more approachable for new contributors and thus more inclusive of other Ruby core members outside of Shopify, which would be great for the long-term future of Ruby. # Current Status It is still early days for ZJIT. We are only 3 months into its development. As such, ZJIT is currently very much incomplete and can only run small tests and microbenchmarks. Nonetheless, we would still like to upstream it because developing in a fork makes it much harder to keep up with upstream changes in Ruby. We’re hoping to bring it much farther along this year, and we believe that ZJIT will be fairly unintrusive in the upstream repo given that it will have no more dependencies than YJIT, and it will also be guarded by a command-line switch. Ruby 3.5 / 2025 Objectives Our goal for the end of the year is to bring ZJIT approximately at parity with YJIT in terms of performance. We expect that it will be relatively easy to outperform YJIT on small microbenchmarks, but that matching YJIT’s performance across larger Ruby programs will take several months because of the breadth of Ruby features used. It is non-trivial to efficiently handle megamorphic call sites making use of keyword arguments, for instance. It should not be difficult to bring ZJIT at parity with YJIT in terms of supported/unsupported Ruby features, because the JIT compiler can always fall back to the interpreter for any feature it doesn’t support. Some features we aim to implement/complete in time for Ruby 3.5: - Fast JIT-to-JIT calls using a custom calling convention - Polymorphic inline caches - Support for full deoptimization (e.g. for TracePoint) - Ability to deoptimize single functions (e.g. method redefined, caller gets deoptimized) - Side-exit much less often than YJIT (crucial for good performance) - Ability to serialize machine code - Dead-code elimination, constant propagation - Fusion of comparison and branch instructions Stretch goals and longer-term goals: - Support two JIT compilation tiers - Aggressive inlining of Ruby calls - Optimize GC allocations - Allocation elision to speed up allocations and reduce GC pressure We are currently using a modified/improved version of the YJIT backend to generate machine code. This means ZJIT is coming out of the gate with support for both x86-64 and arm64, as YJIT did. The ability to serialize machine code is something that we hope to be able to implement in ZJIT. This would allow us to save compiled code and reuse it in future executions of a given program. This would enable faster startup times. We know from experience that this is important in production environments such as Shopify’s where code can be (re)deployed several times a day, but it also makes sense on a smaller scale where individuals run code on a personal computer and can benefit from software starting up faster. # Merging Logistics Like its predecessor, ZJIT is written in Rust, and has very few dependencies by design. In particular, there are no external dependencies outside of the Rust compiler (rustc) to build ZJIT with Ruby. Given that it is very early in ZJIT’s development process, we would like to upstream ZJIT without replacing YJIT, so as to ensure that Ruby 3.5 ships with a well-tested, production-ready JIT. As with YJIT, we would like to suggest that ZJIT should be guarded by a --zjit command-line switch. Since using the compiler is opt-in, there is very little risk for the average Ruby user. We can adjust the way we advertise ZJIT at the time of the Ruby 3.5 release and how much we want the broader Ruby community to try it based on its level of maturity at that point. If ZJIT is not sufficiently mature, we can simply tell people that it is experimental and only for enthusiasts, and recommend that they use YJIT instead. We are currently developing ZJIT using Rust 1.85.0 so that we can use the 2024 edition of Rust. This shouldn’t be a problem since Rust can easily be installed using the rustup tool, and if a sufficiently recent Rust compiler is not available, CRuby can still build without ZJIT, or with YJIT only (YJIT requires rustc 1.58.0). In terms of build strategy, if a recent version of the Rust cargo tool is installed, it may be possible to automatically build both YJIT and ZJIT in the same binary. Otherwise, YJIT could be built without ZJIT as long as rustc 1.58.0 or more a recent version is available. If neither is available, then CRuby can be built without either JIT as a fallback. Another possibility, if we want to be more conservative for Ruby 3.5, is to only enable building ZJIT if configure is run with an explicit --enable-zjit. We can potentially make this decision closer to the end of the year. The timeline for upstreaming would be in the 4 to 6 weeks following RubyKaigi. To merge ZJIT upstream, we will rebase the commits on ruby/ruby‘s master branch and generally preserve the commit history. Some commit messages will be cleaned up and improved prior to merging. Some commits which are logically related may be squashed together. We will only enable a small subset of CI tests for ZJIT at first, so as to keep all tests passing. -- https://bugs.ruby-lang.org/

4 7