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

[ruby-core:125269] [Ruby Misc#22000] Requesting to be a co-maintainer of ostruct
by Eregon (Benoit Daloze) 14 Apr '26

14 Apr '26

Issue #22000 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #22000: Requesting to be a co-maintainer of ostruct https://bugs.ruby-lang.org/issues/22000 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I would like to become a co-maintainer of the `ostruct` gem (OpenStruct class). I know currently @marcandre is the maintainer of `ostruct` but he seems less active recently (e.g. [open PRs](https://github.com/ruby/ostruct/pulls)) and I would like to become co-maintainer. My particular interest in `ostruct` is that I would like to fix the performance, the current implementation calls `define_singleton_method` for every `ostruct.foo` which is extremely inefficient for all Ruby implementations and all JITs. This has led to basically deprecating `OpenStruct` in its documentation and in some RuboCop rules. However a much faster and simpler implementation would be to rely on `method_missing` which [I have explored in the past](https://github.com/ruby/ostruct/issues/51). This speeds up reading OpenStruct attributes by 6.6x to 2096x. There are compatibility concern so this requires evaluating carefully what OpenStruct subclasses do and might require bumping the major version. I would love to get @marcandre 's opinion on this request but I'm not sure when he will see this. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125234] [Ruby Bug#21990] [ruby-talk:444791] Regression: Ruby 4.0 constantly crashing
by zenspider (Ryan Davis) 14 Apr '26

14 Apr '26

Issue #21990 has been reported by zenspider (Ryan Davis). ---------------------------------------- Bug #21990: [ruby-talk:444791] Regression: Ruby 4.0 constantly crashing https://bugs.ruby-lang.org/issues/21990 * Author: zenspider (Ryan Davis) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- (Filed for a user on ruby-talk who can't get registered here for some reason) After upgrade to ruby 4.0, all our Rails applications are continuously crashing on different nodes at different locations. All the applications were running flawlessly for about a year with 4.0.0.p1 and 4.0.0.p2. Reverting to 4.0.0.p2 solves the issue. The behaviour is the same with 4.0.0 and 4.0.1, where 4.0.1 has the additional issue that the value of ulimit "unlimited" has been reduced below "EFBIG", so no coredumps can be written ("too big"). Bug reporting is not possible: After registering an account on https://bugs.ruby-lang.org/, one is requested to follow the instructions in an e-mail, but such e-mail is never sent; not even after repeatedly requesting it. Versions tried: 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [amd64-freebsd14] 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [amd64-freebsd14] FreeBSD-PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294359 Stuff reported in the logfile (example): ``` Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/activesupport-8.0.1/lib/active_support/core_ext/date/calculations.rb:156: [BUG] Segmentation fault at 0x0000000000000000 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [amd64-freebsd14] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: -- Control frame information ----------------------------------------------- Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0017 p:---- s:0112 e:000111 l:y b:---- CFUNC :<=> Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0016 p:0021 s:0107 e:000106 l:y b:0001 METHOD /ext/gems/4.0/gems/activesupport-8.0.1/lib/active_support/core_ext/date/calculations.rb:156 [FINISH] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0015 p:---- s:0102 e:000101 l:y b:---- CFUNC :< Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0014 p:0150 s:0097 e:000096 l:y b:0001 METHOD /ext/rapp/fin_prod/releases/20260408164852/app/jobs/quote_fetch_job.rb:28 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0013 p:0053 s:0084 e:000083 l:y b:0001 METHOD /ext/gems/4.0/gems/que-2.4.1/lib/que/job_methods.rb:51 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0012 p:0003 s:0073 e:000072 l:y b:0001 METHOD <internal:kernel>:91 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0011 p:0007 s:0069 e:000068 l:n b:---- BLOCK /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:103 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0010 p:0002 s:0066 e:000065 l:n b:---- BLOCK (eval at /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:14):11 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0009 p:0027 s:0063 e:000062 l:y b:0001 METHOD /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:41 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0008 p:0011 s:0053 e:000052 l:n b:---- BLOCK /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:37 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0007 p:0002 s:0050 e:000049 l:y b:0001 METHOD /ext/gems/4.0/gems/que-2.4.1/lib/que/active_record/connection.rb:33 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0006 p:0021 s:0045 e:000044 l:y b:0001 METHOD /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:36 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0005 p:0024 s:0035 e:000034 l:y b:0001 METHOD (eval at /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:14):11 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0004 p:0050 s:0029 e:000028 l:y b:0001 METHOD /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:103 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0003 p:0068 s:0012 e:000011 l:y b:0001 METHOD /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:76 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0002 p:0026 s:0006 e:000005 l:n b:---- BLOCK /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:46 [FINISH] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: c:0001 p:---- s:0003 e:000002 l:y b:---- DUMMY [FINISH] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: -- Ruby level backtrace information ---------------------------------------- Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:46:in 'block in initialize' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:76:in 'work_loop' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:103:in 'work_job' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: (eval at /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:14):11:in 'run_job_middleware' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:36:in 'invoke_middleware' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/active_record/connection.rb:33:in 'call' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:37:in 'block in invoke_middleware' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:41:in 'invoke_middleware' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: (eval at /ext/gems/4.0/gems/que-2.4.1/lib/que/utils/middleware.rb:14):11:in 'block in run_job_middleware' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/worker.rb:103:in 'block in work_job' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: <internal:kernel>:91:in 'tap' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/que-2.4.1/lib/que/job_methods.rb:51:in '_run' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/rapp/fin_prod/releases/20260408164852/app/jobs/quote_fetch_job.rb:28:in 'run' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/rapp/fin_prod/releases/20260408164852/app/jobs/quote_fetch_job.rb:28:in '<' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/activesupport-8.0.1/lib/active_support/core_ext/date/calculations.rb:156:in 'compare_with_coercion' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/activesupport-8.0.1/lib/active_support/core_ext/date/calculations.rb:156:in '<=>' Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: -- Threading information --------------------------------------------------- Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Total ractor count: 1 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Ruby thread count for this ractor: 6 Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: -- C level backtrace information ------------------------------------------- Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_profile_frame_full_label+0x233e) [0x822ec5e2e] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_bug_reporter_add) [0x822cc5b00] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(ruby_sig_finalize) [0x822e09934] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /lib/libthr.so.3(pthread_sigmask+0x556) [0x8294dba16] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /lib/libthr.so.3(pthread_signals_unblock_np) [0x8294daf0a] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: [0x821b682d3] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_gc_adjust_memory_usage) [0x822cf7e5e] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_gc_writebarrier+0xdd) [0x822ce66fd] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/date-3.5.1/lib/date_core.so(Init_date_core+0x145) [0x830904b65] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /ext/gems/4.0/gems/date-3.5.1/lib/date_core.so(Init_date_core+0xa5) [0x8308f5655] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(ruby_free_at_exit_p) [0x822eb5106] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_error_arity) [0x822e97827] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_error_arity) [0x822e90b08] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_check_funcall) [0x822ea0571] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_scan_args_kw) [0x822c33448] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(ruby_free_at_exit_p) [0x822eb5106] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_error_arity) [0x822e97827] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_error_arity) [0x822e90b9b] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_proc_ractor_make_shareable) [0x822ea6e94] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_proc_ractor_make_shareable) [0x822ea62fa] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_internal_thread_specific_set) [0x822e607ec] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_internal_thread_specific_set) [0x822e5ff39] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /usr/local/lib/libruby40.so.40(rb_internal_thread_specific_set) [0x822e5fa01] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: /lib/libthr.so.3(pthread_create) [0x8294d1d68] Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: -- Other runtime information ----------------------------------------------- Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: * Loaded script: /ext/gems/4.0/bin/que Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: * Ruby Box: disabled Apr 9 00:30:24 <daemon.notice> rail rails-fin_prod[73556]: * Loaded features: [etc.etc.] ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default
by byroot (Jean Boussier) 14 Apr '26

14 Apr '26

Issue #20205 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20205: Enable `frozen_string_literal` by default https://bugs.ruby-lang.org/issues/20205 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context The `frozen_string_literal: true` pragma was introduced in Ruby 2.3, and as far as I'm aware the plan was initially to make it the default for Ruby 3.0, but this plan was abandoned because it would be too much of a breaking change without any real further notice. According to Matz, he still wishes to enable `frozen_string_literal` by default in the future, but a reasonable migration plan is required. The main issue is backward compatibility, flipping the switch immediately would break a lot of code, so there must be some deprecation period. The usual the path forward for this kind of change is to emit deprecation warnings one of multiple versions in advance. One example of that was the Ruby 2.7 keyword argument deprecation. It was quite verbose, and some users were initially annoyed, but I think the community pulled through it and I don't seem to hear much about it anymore. So for frozen string literals, the first step would be to start warning when a string that would be frozen in the future is mutated. ### Deprecation Warning Implementation I implemented a quick proof of concept with @etienne in https://github.com/Shopify/ruby/pull/549 In short: - Files with `# frozen_string_literal: true` or `# frozen_string_literal: false` don't change in behavior at all. - Files with no `# frozen_string_literal` comment are compiled to use `putchilledstring` opcode instead of regular `putstring`. - This opcode mark the string with a user flag, when these strings are mutated, a warning is issued. Currently the proof of concept issue the warning at the mutation location, which in some case can make locating where the string was allocated a bit hard. But it is possible to improve it so the message also include the location at which the literal string was allocated, and learning from the keyword argument warning experience, we can record which warnings were already issued to avoid spamming users with duplicated warnings. As currently implemented, there is almost no overhead. If we modify the implementation to record the literal location, we'd incur a small memory overhead for each literal string in a file without an explicit `frozen_string_literal` pragma. But I believe we could do it in a way that has no overhead if `Warning[:deprecated] = false`. ### Timeline The migration would happen in 3 steps, each step can potentially last multiple releases. e.g. `R0` could be `3.4`, `R1` be `3.7` and `R2` be `4.0`. I don't have a strong opinion on the pace. - Release `R0`: introduce the deprecation warning (only if deprecation warnings enabled). - Release `R1`: make the deprecation warning show up regardless of verbosity level. - Release `R2`: make string literals frozen by default. ### Impact Given that `rubocop` is quite popular in the community and it has enforced the usage of `# frozen_string_literal: true` for years now, I suspect a large part of the actively maintained codebases in the wild wouldn't see any warnings. And with recent versions of `minitest` enabling deprecation warnings by default (and [potentially RSpec too](https://github.com/rspec/rspec-core/issues/2867)) the few that didn't migrate will likely be made compatible quickly. The real problem of course are the less actively developed libraries and applications. For such cases, any codebase can remain compatible by setting `RUBYOPT="--disable=frozen_string_literal"`, and so even after `R2` release. The flag would never be removed any legacy codebase can continue upgrading Ruby without changing a single line of cod by just flipping this flag. ### Workflow for library maintainers As a library maintainer, fixing the deprecation warnings can be as simple as prepending `# frozen_string_literal: false` at the top of all their source files, and this will keep working forever. Alternatively they can of course make their code compatible with frozen string literals. Code that is frozen string literal compatible doesn't need to explicitly declare it. Only code that need it turned of need to do so. ### Workflow for application owners For application owners, the workflow is the same than for libraries. However if they depend on a gem that hasn't updated, or that they can't upgrade it, they can run their application with `RUBYOPT="--disable=frozen_string_literal"` and it will keep working forever. Any user running into an incompatibility issue can set `RUBYOPT="--disable=frozen_string_literal"` forever, even in `4.x`, the only thing changing is the default value. And any application for which all dependencies have been made fully frozen string literal compatible can set `RUBYOPT="--enable=frozen_string_literal"` and start immediately removing magic comment from their codebase. -- https://bugs.ruby-lang.org/

23 82

[ruby-core:125143] [Ruby Misc#21968] The pathname gem needs a new release
by Eregon (Benoit Daloze) 14 Apr '26

14 Apr '26

Issue #21968 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21968: The pathname gem needs a new release https://bugs.ruby-lang.org/issues/21968 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- The current pathname gem release (0.4.0) has several issues: ### Many warnings on Ruby 4.0 It emits many constant & method redefinition warnings. This happens notably when an application has `pathname` as a dependency (direct or transitive) in the Gemfile. This is with the default `$VERBOSE`: ``` $ gem i pathname $ ruby -e 'gem "pathname"; require "pathname"' /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:17: warning: already initialized constant Pathname::VERSION <internal:pathname_builtin>:194: warning: previous definition of VERSION was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:36: warning: already initialized constant Pathname::SEPARATOR_LIST <internal:pathname_builtin>:312: warning: previous definition of SEPARATOR_LIST was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:37: warning: already initialized constant Pathname::SEPARATOR_PAT <internal:pathname_builtin>:313: warning: previous definition of SEPARATOR_PAT was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:43: warning: already initialized constant Pathname::ABSOLUTE_PATH <internal:pathname_builtin>:323: warning: previous definition of ABSOLUTE_PATH was here ``` And 53 warnings with `-w`: ``` $ ruby -we 'gem "pathname"; require "pathname"' /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:17: warning: already initialized constant Pathname::VERSION <internal:pathname_builtin>:194: warning: previous definition of VERSION was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:36: warning: already initialized constant Pathname::SEPARATOR_LIST <internal:pathname_builtin>:312: warning: previous definition of SEPARATOR_LIST was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:37: warning: already initialized constant Pathname::SEPARATOR_PAT <internal:pathname_builtin>:313: warning: previous definition of SEPARATOR_PAT was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:43: warning: already initialized constant Pathname::ABSOLUTE_PATH <internal:pathname_builtin>:323: warning: previous definition of ABSOLUTE_PATH was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:50: warning: method redefined; discarding old chop_basename <internal:pathname_builtin>:359: warning: previous definition of chop_basename was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:61: warning: method redefined; discarding old split_names <internal:pathname_builtin>:370: warning: previous definition of split_names was here ... ``` See https://github.com/ruby/pathname/issues/66 ### The gem fails to install on JRuby See https://github.com/ruby/pathname/issues/94#issuecomment-4016566593 ### The gem crashes on TruffleRuby It causes errors like `pathname.so: undefined symbol: rb_block_call_kw`. See https://github.com/ruby/pathname/issues/94#issue-4038536603 ### Release request These 3 issues are fixed on ruby/pathname master by https://github.com/ruby/pathname/pull/56 and https://github.com/ruby/pathname/pull/57, but no release including those fixes has been published yet. I also opened a GitHub issue about the release request here: https://github.com/ruby/pathname/issues/94. Would it be possible to make a new pathname release? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125164] [Ruby Feature#21975] Add "UTF-八" as an alias for UTF-8 encoding
by ko1 (Koichi Sasada) 14 Apr '26

14 Apr '26

Issue #21975 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #21975: Add "UTF-八" as an alias for UTF-8 encoding https://bugs.ruby-lang.org/issues/21975 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- In Japan, legal texts must write all characters - including digits - using full-width or kanji forms. As a result, the encoding name "UTF-8" appears as "UTF-八" (八 = eight in kanji) in official government notices. Specifically, it appears in a notice issued by the Digital Agency and the Ministry of Internal Affairs and Communications (令和8年デジタル庁・総務省告示第12号), which defines character sets and encoding for local government information systems: > 地方公共団体情報システムの標準化に関する法律第七条第一項に規定する各地方公共団体情報システムに共通する基準のうち電磁的記録において用いられる用語及び符号の相互運用性の確保その他の地方公共団体情報システムに係る互換性の確保に関する標準を定める命令第三条第二号の規定に基づき行政事務標準文字の文字セット及び地方公共団体情報システム間の連携のための文字符号化方式を定める告示 Reference: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resourc… This patch <https://github.com/ruby/ruby/pull/16623> adds "UTF-八" as an encoding alias for UTF-8, so that Ruby is compliant with Japanese law. ```ruby # encoding: UTF-八 p __ENCODING__ #=> #<Encoding:UTF-8> p Encoding.find("UTF-八") #=> #<Encoding:UTF-8> p "hello".encode("UTF-八") #=> "hello" p "こんにちは".force_encoding("UTF-八") #=> "こんにちは" p "こんにちは".encode("ＵＴＦ｜八") #=> "こんにちは" ``` -- https://bugs.ruby-lang.org/

5 5

[ruby-core:125253] [Ruby Bug#21997] segfault in basicobject
by danielchong (Daniel Chong) 13 Apr '26

13 Apr '26

Issue #21997 has been reported by danielchong (Daniel Chong). ---------------------------------------- Bug #21997: segfault in basicobject https://bugs.ruby-lang.org/issues/21997 * Author: danielchong (Daniel Chong) * Status: Open * ruby -v: 4.1.0dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ./ruby script.rb ``` [0, 1, -1, 10000000000000000000000, -10000000000000000000000].each do |val| begin class BasicObject def initialize(v); @v = v; end def to_s; @v.to_s; end end obj = BasicObject.new(val) p [:required_after, TOPLEVEL_BINDING.local_variables] s = val.to_s.force_encoding(Encoding::UTF_8) s.codepoints if s.valid_encoding? binding.eval("v = #{val}; [:test, v, TOPLEVEL_BINDING.local_variables]") rescue => e end end ``` `RubyGems' were not loaded. `error_highlight' was not loaded. `did_you_mean' was not loaded. `syntax_suggest' was not loaded. ==575066==WARNING: ASan is ignoring requested __asan_handle_no_return: stack type: default top: 0x7ffd6e104000; bottom 0x55d86e96b000; size: 0x2a24ff799000 (46338393346048) False positive error reports may follow For details see https://github.com/google/sanitizers/issues/189 d1d8e75b87fbf5baa84c:6: [BUG] Segmentation fault at 0x0000000000000094 ruby 4.1.0dev (2026-04-11T12:02:54Z master f70c081b8f) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:0003 s:0020 e:000019 l:y b:0001 r:(nil) CLASS d1d8e75b87fbf5baa84c:6 c:0004 p:0007 s:0017 e:000016 l:n b:---- r:(nil) BLOCK d1d8e75b87fbf5baa84c:5 [FINISH] c:0003 p:---- s:0010 e:000009 l:y b:---- r:(nil) CFUNC :each c:0002 p:0005 s:0006 e:000005 l:n b:---- r:(nil) EVAL d1d8e75b87fbf5baa84c:2 [FINISH] c:0001 p:0000 s:0003 E:001730 l:y b:---- r:(nil) DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- d1d8e75b87fbf5baa84c:2:in '<main>' d1d8e75b87fbf5baa84c:2:in 'each' d1d8e75b87fbf5baa84c:5:in 'block in <main>' d1d8e75b87fbf5baa84c:6:in '<class:BasicObject>' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x000055d86dbaee31 RBP: 0x00007ffd6e101cd0 RSP: 0x00007ffd6e101be0 RAX: 0x0000000000000004 RBX: 0x0000147aa3133980 RCX: 0x0000000000000000 RDX: 0x0000000000000000 RDI: 0x0000147aa31339b0 RSI: 0x0000502000001590 R8: 0x0000000000000001 R9: 0x000051300000eef8 R10: 0x00007ffd6e101060 R11: 0x0000028f54626750 R12: 0x0000147aa3133a20 R13: 0x0000000000000001 R14: 0x0000028f54626730 R15: 0x0000000000000001 EFL: 0x0000000000010246 -- C level backtrace information ------------------------------------------- /lib/x86_64-linux-gnu/libasan.so.8(___interceptor_backtrace+0x60) [0x147aa54c91e0] ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4358 /home/w023dtc/ruby/build/ruby(rb_print_backtrace+0x8) [0x55d86dfbc812] ../vm_dump.c:1108 /home/w023dtc/ruby/build/ruby(rb_vm_bugreport) ../vm_dump.c:1456 /home/w023dtc/ruby/build/ruby(rb_bug_for_fatal_signal+0x20d) [0x55d86e399ffd] ../error.c:1140 /home/w023dtc/ruby/build/ruby(sigsegv+0x88) [0x55d86dd994b8] ../signal.c:948 /lib/x86_64-linux-gnu/libc.so.6(0x147aa5086330) [0x147aa5086330] /home/w023dtc/ruby/build/ruby(rb_estimate_iv_count+0x211) [0x55d86dbaee31] ../iseq.c:3032 /home/w023dtc/ruby/build/ruby(RCLASS_SET_MAX_IV_COUNT+0x0) [0x55d86df7c06e] ../vm_insnhelper.c:6054 /home/w023dtc/ruby/build/ruby(vm_define_method) ../vm_insnhelper.c:6054 /home/w023dtc/ruby/build/ruby(vm_exec_core+0xac0) [0x55d86df89270] ../insns.def:837 /home/w023dtc/ruby/build/ruby(rb_vm_exec+0x2ee) [0x55d86df58c6e] ../vm.c:2810 /home/w023dtc/ruby/build/ruby(invoke_block_from_c_bh+0x6c6) [0x55d86df65b26] ../vm.c:1832 /home/w023dtc/ruby/build/ruby(rb_yield+0x1d1) [0x55d86df69451] ../vm.c:1883 /home/w023dtc/ruby/build/ruby(RB_FL_TEST_RAW+0x0) [0x55d86e1368ac] ../array.c:2766 /home/w023dtc/ruby/build/ruby(RB_FL_ANY_RAW) ../include/ruby/internal/fl_type.h:455 /home/w023dtc/ruby/build/ruby(rb_array_len) ../include/ruby/internal/core/rarray.h:259 /home/w023dtc/ruby/build/ruby(rb_ary_each) ../array.c:2765 /home/w023dtc/ruby/build/ruby(vm_cfp_consistent_p+0x0) [0x55d86df1cf96] ../vm_insnhelper.c:3914 /home/w023dtc/ruby/build/ruby(vm_call_cfunc_with_frame_) ../vm_insnhelper.c:3916 /home/w023dtc/ruby/build/ruby(vm_call_method_each_type+0x221) [0x55d86df5c101] ../vm_insnhelper.c:4900 /home/w023dtc/ruby/build/ruby(vm_call_method+0x2b4) [0x55d86df5f2d4] ../vm_insnhelper.c:5052 /home/w023dtc/ruby/build/ruby(vm_sendish+0x312) [0x55d86df3ba62] ../vm_insnhelper.c:6138 /home/w023dtc/ruby/build/ruby(vm_exec_core+0x8e6) [0x55d86df89096] ../insns.def:864 /home/w023dtc/ruby/build/ruby(rb_vm_exec+0x2ee) [0x55d86df58c6e] ../vm.c:2810 /home/w023dtc/ruby/build/ruby(rb_iseq_eval_main+0x18a) [0x55d86df9dcfa] ../vm.c:3106 /home/w023dtc/ruby/build/ruby(rb_ec_exec_node+0x2ab) [0x55d86da4ef0b] ../eval.c:284 /home/w023dtc/ruby/build/ruby(ruby_run_node+0xfe) [0x55d86da564ce] ../eval.c:322 /home/w023dtc/ruby/build/ruby(rb_main+0x21) [0x55d86da458f2] ../main.c:42 /home/w023dtc/ruby/build/ruby(main) ../main.c:62 /lib/x86_64-linux-gnu/libc.so.6(0x147aa506b1ca) [0x147aa506b1ca] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x147aa506b28b] [0x55d86da46f25] -- Other runtime information ----------------------------------------------- * Loaded script: d1d8e75b87fbf5baa84c * Ruby Box: disabled * Loaded features: 0 enumerator.so 1 monitor.so 2 thread.rb 3 fiber.so 4 rational.so 5 complex.so 6 pathname.so 7 ruby2_keywords.rb 8 set.rb AddressSanitizer:DEADLYSIGNAL Segmentation fault (core dumped) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:125237] [Ruby Bug#21992] Defining BasicObject#initialize causes segmentation fault
by petercooper (Peter Cooper) 12 Apr '26

12 Apr '26

Issue #21992 has been reported by petercooper (Peter Cooper). ---------------------------------------- Bug #21992: Defining BasicObject#initialize causes segmentation fault https://bugs.ruby-lang.org/issues/21992 * Author: petercooper (Peter Cooper) * Status: Open * ruby -v: 4.0.2 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Simplest reproduction: ``` ruby class BasicObject def initialize end end ``` In Ruby HEAD, 4.0.2, 3.4.7, and 3.3.11 on macOS, this leads to an immediate segmentation fault. I also got this on Ruby 3.4.1 on Linux. What I would expect, a warning similar to that raised if you do the same on `Object`. I couldn't find a previous mention of this. It's not something you would ever write yourself, but I guess it could arise during metaprogramming or dynamic code generation with the right (wrong) constant name in play. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:123836] [Ruby Feature#21695] Optimizing Ruby performance with Ruby itself instead of Rust
by fredlinhares (Frederico Linhares) 10 Apr '26

10 Apr '26

Issue #21695 has been reported by fredlinhares (Frederico Linhares). ---------------------------------------- Feature #21695: Optimizing Ruby performance with Ruby itself instead of Rust https://bugs.ruby-lang.org/issues/21695 * Author: fredlinhares (Frederico Linhares) * Status: Open ---------------------------------------- I am using ERB on top of C for a game I am making now. We can use the tool to improve the productivity, memory safety, and runtime speed for Ruby. It can also replace a Rust JIT compiler for better results. The only problem is that it requires some level of manual memory management, while Rust does it all for you. If I demonstrate that it is better than Rust in practice, would you be willing to incorporate it into the Ruby language? I want to know because making it more generic will require more effort from me; if you are not interested, I won’t make the tool public. -- https://bugs.ruby-lang.org/

6 10

[ruby-core:125217] [Ruby Feature#21987] Assume `chdir(2)` isn't called and cache `rb_dir_getwd_ospath()`
by byroot (Jean Boussier) 10 Apr '26

10 Apr '26

Issue #21987 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21987: Assume `chdir(2)` isn't called and cache `rb_dir_getwd_ospath()` https://bugs.ruby-lang.org/issues/21987 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context I'm looking at optimizing Ruby applications boot time, and one very common operation that seems wasteful is that when interpreting relative paths we keep calling `ruby_getcwd()`, even though its result almost never changes (`Dir.chdir` calls are rare). We have 3 distinct implementations of `ruby_getcwd()` depending on the platform, but generally speaking it involves: - One or multiple syscalls (on macOS: `open` + `fnctl` + `stat` + `close`). - `malloc` + `free` - `strdup` + `free` - For some implementations, allocating a `T_DATA` to avoid leaks in case of failure. ### Measure Out of curiosity I measured our monolith. Just booting we end up calling `getcwd(2)` `6931` times, for a total of `90ms` spent in `rb_dir_getwd_ospath()`, but the caching would allow to save a bit more than that, as callers would no longer need to manage that memory. ### Proposal I propose that we cache the result of `ruby_getcwd()`, and only flush the cache when `Dir.chdir` is called. ### Compatibility concern This however assumes that C extensions or other native libraries never call `chdir(2)` after executing Ruby, or at least always reset it before yielding back to Ruby. I'm not aware of any C extension currently doing this, but it would be interesting to perform a `gem-codesearch`. If necessary we can provide `void ruby_cwd_changed(void)` to reset the cache after calling `chdir(2)`. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:125208] [Ruby Bug#21984] RubyVM::AST can't tell if an array is passed to break/next/return
by kddnewton (Kevin Newton) 09 Apr '26

09 Apr '26

Issue #21984 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21984: RubyVM::AST can't tell if an array is passed to break/next/return https://bugs.ruby-lang.org/issues/21984 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` irb(main):005> RubyVM::AbstractSyntaxTree.parse("tap { break [1, 2, 3] }") => (SCOPE@1:0-1:23 tbl: [] args: nil body: (ITER@1:0-1:23 (FCALL@1:0-1:3 :tap nil) (SCOPE@1:4-1:23 tbl: [] args: nil body: (BREAK@1:6-1:21 (LIST@1:12-1:21 (INTEGER@1:13-1:14 1) (INTEGER@1:16-1:17 2) (INTEGER@1:19-1:20 3) nil))))) irb(main):006> RubyVM::AbstractSyntaxTree.parse("tap { break 1, 2, 3 }") => (SCOPE@1:0-1:21 tbl: [] args: nil body: (ITER@1:0-1:21 (FCALL@1:0-1:3 :tap nil) (SCOPE@1:4-1:21 tbl: [] args: nil body: (BREAK@1:6-1:19 (LIST@1:12-1:19 (INTEGER@1:12-1:13 1) (INTEGER@1:15-1:16 2) (INTEGER@1:18-1:19 3) nil))))) irb(main):007> ``` The issue is, `break [1, 2, 3]` has the same AST as `break 1, 2, 3` (presumably because they are effectively the same thing). But a consumer has no way to know if an array was used short of re-parsing the source. -- https://bugs.ruby-lang.org/

3 4