March 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:124920] [Ruby Bug#21941] Local variable becomes nil when YJIT enabled mid-method with fork/signal/ensure
by nicholasdower (Nick Dower) 09 May '26

09 May '26

Issue #21941 has been reported by nicholasdower (Nick Dower). ---------------------------------------- Bug #21941: Local variable becomes nil when YJIT enabled mid-method with fork/signal/ensure https://bugs.ruby-lang.org/issues/21941 * Author: nicholasdower (Nick Dower) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following code results in the `read` local variable becoming nil, even though it is never reassigned: ``` def run fork_safe = ->(t) { t } RubyVM::YJIT.enable read, wakeup = IO.pipe Signal.trap("SIGCHLD") { wakeup.write("!") } begin while true begin fork { exit } next if read.wait_readable rescue Interrupt end end ensure end end run ``` Error: ``` repro.rb:13:in 'Object#run': undefined method 'wait_readable' for nil (NoMethodError) next if read.wait_readable ^^^^^^^^^^^^^^ from repro.rb:21:in '<main>' ``` See also: https://github.com/puma/puma/issues/3620 https://github.com/Shopify/ruby/issues/625 -- https://bugs.ruby-lang.org/

5 5

[ruby-core:124655] [Ruby Bug#21856] Nokogiri performance degradation since Ruby 4.0
by ahorek 30 Apr '26

30 Apr '26

Issue #21856 has been reported by ahorek (Pavel Rosický). ---------------------------------------- Bug #21856: Nokogiri performance degradation since Ruby 4.0 https://bugs.ruby-lang.org/issues/21856 * Author: ahorek (Pavel Rosický) * Status: Open * ruby -v: ruby 4.1.0dev (2026-01-31T09:41:30Z master 7ef8c470d2) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Loofah sanitization is noticeably slower ``` Ruby: 3.4.8 Loofah: 2.25.0 Nokogiri: 1.19.0 Iterations: 100000 user system total real Loofah.fragment + scrub!(:prune) 26.091872 0.000000 26.091872 ( 25.110925) Loofah.scrub_fragment(:prune) 25.913185 0.010392 25.923577 ( 24.948464) Nokogiri HTML parse only 3.852690 0.000000 3.852690 ( 3.705930) Ruby: 4.0.0 & 4.0.1 Loofah: 2.25.0 Nokogiri: 1.19.0 Iterations: 100000 user system total real Loofah.fragment + scrub!(:prune) 38.094207 0.041753 38.135960 ( 36.669463) Loofah.scrub_fragment(:prune) 40.168795 0.000045 40.168840 ( 38.561806) Nokogiri HTML parse only 4.012936 0.052024 4.064960 ( 3.913272) Ruby: 4.1.0 (ruby 4.1.0dev (2026-01-31T09:41:30Z master 7ef8c470d2) +PRISM [x86_64-linux]) Loofah: 2.25.0 Nokogiri: 1.19.0 Iterations: 100000 user system total real Loofah.fragment + scrub!(:prune) 39.004228 0.000000 39.004228 ( 37.694873) Loofah.scrub_fragment(:prune) 39.043199 0.031284 39.074483 ( 37.182785) Nokogiri HTML parse only 3.889100 0.010427 3.899527 ( 3.741622) ``` Originally reported https://www.redmine.org/issues/43737 ---Files-------------------------------- benchmark.rb (1002 Bytes) -- https://bugs.ruby-lang.org/

9 14

[ruby-core:124726] [Ruby Feature#21871] Add Module#undef_const
by jeremyevans0 (Jeremy Evans) 29 Apr '26

29 Apr '26

Issue #21871 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21871: Add Module#undef_const https://bugs.ruby-lang.org/issues/21871 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- I propose to add `Module#undef_const`, which would operate for constants similarly to how `undef_method` (and the `undef` keyword) works for methods. When an undefed constant is found during constant lookup, lookup stops, and results in `const_missing` being called (similar to how `undef_method` stops method lookup and results in `method_missing` being called). The expected use for this is for stopping direct access to global constants inside namespaces. For example: ```ruby class DangerousClass; end class SafeClass undef_const :DangerousClass DangerousClass # NameError (const_missing behavior) end DangerousClass # no error ``` You cannot implement this behavior without introducing the equivalent of `Module#undef_const`. The best you can do is define a constant in the namespace that raises later when there is some access to the returned object. However, that approach has significant limitations, since you cannot raise on the lookup, only later when something operates on the returned object: ```ruby class DangerousClass; end class SafeClass DangerousClass = BasicObject.new DangerousClass.foo # NoMethodError DangerousClass::Constant # TypeError def m # doesn't raise, NoMethodError/TypeError occurs potentially much later in unrelated code [DangerousClass] end end ``` As to why it is good to stop direct access to a particular constants inside a namespace, it helps avoid IDOR (insecure direct object reference) security issues, since it pushes you to use a style like: ```ruby # Find a bar related to this foo bar = foo.bars.find { it.id == some_id } ``` As opposed to: ```ruby bar = Bar.find { it.id == some_id && it.foo.id == foo.id } ``` Assuming these are equivalent, the first approach is still better, because it avoids the possibility that a developer can write the following, missing the necessary check that the bar being accessed is related to the foo: ```ruby bar = Bar.find { it.id == some_id } ``` By using `undef_const :Bar` in the namespace, the `Bar.find` approach will not work, and developers will be pushed to use the `foo.bars.find` approach, which enforces safer behavior. I've submitted a pull request that implements this proposal: https://github.com/ruby/ruby/pull/16116 -- https://bugs.ruby-lang.org/

4 4

[ruby-core:125114] [Ruby Feature#21962] Add deep_freeze for recursive freezing
by Eregon (Benoit Daloze) 21 Apr '26

21 Apr '26

Issue #21962 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21962: Add deep_freeze for recursive freezing https://bugs.ruby-lang.org/issues/21962 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- ### Motivation It is common to want some data structure to be immutable, e.g. to ensure it doesn't get mutated by multiple threads. See the first section of #21665 for a more detailed motivation, the summary is there is long-standing demand for it (back to #17145) for many reasons. One way/workaround to do this currently is `Ractor.make_shareable` but its name suggests a Ractor-specific purpose. The functionality of deeply freezing is separate from Ractor and it is generally useful. `Ractor.make_shareable` almost has the right semantics and has been used for years so this proposal largely follows its semantics rather than reinventing the wheel. The semantics also match the `ice_nine` gem, which further illustrates these semantics work well in practice and are expected. ### Examples It freezes deeply: ```ruby config = { db: { host: ENV["HOST"], ports: [5432] }, flags: [:a, :b] }.deep_freeze config.frozen? # => true config[:db].frozen? # => true config[:db][:host].frozen? # => true config[:db][:ports].frozen? # => true ``` Modules and classes are not frozen by `deep_freeze`: ```ruby String.deep_freeze String.frozen? # => false ``` It works for cyclic references: ```ruby a = [] a << a a.deep_freeze a.frozen? # => true ``` It calls `.freeze` on each object: ```ruby class Stats def initialize(samples) @samples = samples @mean = nil end def mean @mean ||= @samples.sum / @samples.size.to_f end def freeze mean super end end s = Stats.new([1.0, 2.0, 3.0]) s.deep_freeze s.mean # => 2.0, would raise FrozenError instead if overridden #freeze was not called ``` ### Background #21665 relaunched the discussion about `deep_freeze` and it was [discussed in a dev meeting](https://github.com/ruby/dev-meeting-log/blob/master/2025/DevMeetin…. @headius has said he won't have time to look at it soon. So I am proposing something concrete which hopefully can be approved as-is. ### Design * Proposed: `Kernel#deep_freeze`. Alternative: `Object.deep_freeze`. * `Kernel#deep_freeze` is consistent with `Kernel#freeze`. * `[a, b, c].deep_freeze` is nicer, more concise and more idiomatic than `Object.deep_freeze([a, b, c])`. * The proposal focuses on semantics; the exact method name and owner can be decided separately. * The return value is the receiver. * `deep_freeze` never freezes modules and classes and does not visit their internal references * Same as `Ractor.make_shareable` and `IceNine.deep_freeze` * No unexpected breakage because a class, its ancestors, their constants, etc all got frozen. * Very easy to explain in the documentation. * If people want to freeze classes/modules (rare case) they can with `.freeze` and have control and can decide whether to freeze the ancestors, constants, class variables, etc. * `deep_freeze` calls `freeze` and ensures every object is frozen * Same as `Ractor.make_shareable` and `IceNine.deep_freeze` * The already well-known hook to e.g. compute lazy caches eagerly, etc * We still check that `.freeze` did freeze the object, and raise a `RuntimeError` if not (same behavior and error message as `Ractor.make_shareable`). * Not a protocol of defining `deep_freeze` in many classes. * That does not work with circular references. * No need to invent a complex protocol when there is an existing working one (calling `.freeze`) which has proven to work well (by being used by `Ractor.make_shareable`). * Handling circular references by maintaining internally a set of visited objects to avoid walking circular references multiple times * As done in `obj_traverse_i` in `ractor.c`. * No expectation for calling `deep_freeze` repeatedly on the same object to be fast * An object flag wouldn't work for this, for the case that `freeze` raises an exception. * If some `freeze` method raises an exception, the exception is propagated. * Same as `Ractor.make_shareable` and `IceNine.deep_freeze` * Some objects visited before the exception may already be frozen, same as `Ractor.make_shareable` (unavoidable because we need to call `freeze` as we traverse the object graph). * `deep_freeze` does not stop at already-frozen objects, because they may still reference unfrozen objects. * No special treatment for shareable objects, they are frozen too. I think this addresses all the points mentioned in the [dev meeting discussion](https://github.com/ruby/dev-meeting-log/blob/master/2025/DevMee… and in #21665 and in #17145. The traversal and freezing behavior closely follows `Ractor.make_shareable`, without introducing new semantics. ### Implementation The implementation in CRuby would be shared with `Ractor.make_shareable`, `ractor.c` already provides `rb_obj_traverse()` which is a great fit to implement this. From a high-level view the implementation works like this: `deep_freeze` recursively traverses the reachable object graph from the receiver. For each visited object: * If it is a `Class` or `Module`, it is not frozen and its internal references are not traversed. * Otherwise, Ruby calls `.freeze` on the object. * After calling `freeze`, Ruby verifies that the object is frozen. If it is not frozen, an exception is raised (same behavior and error message as `Ractor.make_shareable`). * The traversal keeps a visited set to avoid infinite recursion on cycles. ### Non-goals This proposal is focused on defining `deep_freeze` and nothing else: * This proposal does not define a new protocol requiring classes to implement custom recursive logic. * This proposal does not change `Ractor.make_shareable`. * This proposal does not freeze classes or modules. * This proposal does not attempt to define immutability as a broader language concept. ### Compatibility and risk * The proposal adds a new API and does not change existing `freeze` behavior. * It intentionally reuses existing `freeze` overrides on user objects. * It intentionally does not freeze classes/modules to avoid surprising breakage. * Its semantics are close to existing `Ractor.make_shareable`, reducing implementation risk. ### Relation to existing methods * `freeze`: freezes only the receiver (shallow). * `deep_freeze`: recursively freezes reachable objects. * `Ractor.make_shareable`: recursively freezes reachable objects except if they are already shareable. Special handling to make some objects shareable. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:124864] [Ruby Misc#21922] Permissions for committers for default/bundled/unbundled gems repositories
by Eregon (Benoit Daloze) 21 Apr '26

21 Apr '26

Issue #21922 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21922: Permissions for committers for default/bundled/unbundled gems repositories https://bugs.ruby-lang.org/issues/21922 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I noticed recently that the team `ruby-committers` on GitHub no longer has write access to at least: * https://github.com/ruby/benchmark * https://github.com/ruby/cmath * https://github.com/ruby/curses * https://github.com/ruby/dbm * https://github.com/ruby/e2mmap * https://github.com/ruby/gdbm * https://github.com/ruby/getoptlong * https://github.com/ruby/iconv * https://github.com/ruby/mathn * https://github.com/ruby/mutex_m * https://github.com/ruby/net-ftp * https://github.com/ruby/net-pop * https://github.com/ruby/net-telnet * https://github.com/ruby/observer * https://github.com/ruby/pathname (marked as maintained by @akr but they don't reply on GitHub, there is also an unclear relation with core Pathname [which still hasn't been resolved](https://github.com/ruby/pathname/issues/66) and is causing warnings for months) * https://github.com/ruby/prime * https://github.com/ruby/pstore * https://github.com/ruby/readline * https://github.com/ruby/readline-ext * https://github.com/ruby/ruby2_keywords * https://github.com/ruby/scanf * https://github.com/ruby/sdbm * https://github.com/ruby/set * https://github.com/ruby/shell * https://github.com/ruby/syck * https://github.com/ruby/sync * https://github.com/ruby/thwait * https://github.com/ruby/tk * https://github.com/ruby/tracer * https://github.com/ruby/webrick * https://github.com/ruby/win32api * https://github.com/ruby/xmlrpc This list is from a couple cases I noticed myself + [all repos](https://github.com/orgs/ruby/repositories?q=mirror%3Afalse+fork%3Afa… - [those committers have access](https://github.com/orgs/ruby/teams/ruby-committers/repositories) - [repos with known maintainers](https://github.com/ruby/ruby/blob/master/doc/maintainers.md)) I filtered manually so there could be some mistake(s), though I tried to check carefully. I am certain CRuby committers had access to some of these repositories (e.g. I merged PRs there), but not sure about all, some might already not have had write access for CRuby committers. It seems only the 4 owners of the Ruby GitHub organization have write access to these repositories. What motivated these changes? I believe it is valuable that all CRuby committers can merge to default/bundled/unbundled gems repositories *without active maintainers*, as it was before. There is [this list](https://github.com/ruby/ruby/blob/master/doc/maintainers.md) to define maintainers, though it's a little bit outdated and inaccurate. It's fine enough for this issue though. (A better definition IMO for active maintainers would be maintainers would actually respond to PRs and issues on GitHub to these repositories otherwise they are effectively not maintaining that repository, at least from an external perspective.) IOW it seems unreasonable to always have to ask one of the 4 owners of the Ruby GitHub organization to merge a PR to such repositories, as it would be a significant overhead for committers and for owners, and it would delay merging PRs significantly. I'm thinking for example to * documentation PRs ([many for pathname](https://github.com/ruby/pathname/pulls)) which really shouldn't need an owner to merge * PRs to improve/fix the CI ([example](https://github.com/ruby/readline-ext/pull/29)) * PRs fixing compatibility with recent changes in ruby's master branch * etc. Yet another way to see this is many default/bundled/unbundled gems do not have active maintainers. AFAIK so far in such cases then all CRuby committers could help, but this seems no longer the case. (FWIW I saw there a `default-gems-contributor` team with 3 people, which explains why they can merge PRs to some repositories that ruby committers can't for example.) -- https://bugs.ruby-lang.org/

6 14

[ruby-core:125117] [Ruby Feature#21963] A solution to completely avoid allocated-but-uninitialized objects
by Eregon (Benoit Daloze) 17 Apr '26

17 Apr '26

Issue #21963 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21963: A solution to completely avoid allocated-but-uninitialized objects https://bugs.ruby-lang.org/issues/21963 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- A common issue when defining a class is to handle allocated-but-uninitialized objects. For example: ```ruby obj = MyClass.allocate obj.some_method ``` This can easily segfault for classes defined in C and raise an unclear exception for classes defined in Ruby. As a workaround many core (and non-core) classes add a check that they are initialized in *every* instance method. This is suboptimal for performance and correctness, classes should not need to care about allocated-but-uninitialized objects. Fundamentally, to solve this we need to guarantee that after the allocation function is used that either `initialize`, `initialize_dup` or `initialize_clone` is called. And we can't guarantee that for `Class#allocate`. The current workarounds are: * `undef allocate`, but this does not prevent `Class.instance_method(:allocate).bind_call(Foo)`. * `rb_undef_alloc_func()` but this breaks `dup`, `clone` and `Marshal`. The idea is to have in addition of the `public alloc function` (in `rb_classext_struct.as.class.allocator`) an `internal alloc function`. Then: * `Class#new`, `dup`, `clone` and `Marshal` always use the internal alloc function, because they guarantee to call `initialize`, `initialize_dup` or `initialize_clone`. * `rb_define_alloc_func()` sets both fields. * `rb_undef_alloc_func()` sets both fields. * `rb_get_alloc_func()` reads the public alloc function (unchanged) * `Class#allocate` uses the public alloc function (unchanged) We add a new method on `Class`, for example `Class#safe_initialization`, which: * Sets the public alloc function to `UNDEF_ALLOC_FUNC`, same as `rb_undef_alloc_func()`, so `Class#allocate` and `rb_get_alloc_func()` will raise if they are used (as they are unsafe). * Preserves the internal alloc function so `Class#new`, `dup`, `clone` and `Marshal` keep working. After that the class has fully safe intialization and does not need to worry about allocated-but-uninitialized objects anymore. From https://bugs.ruby-lang.org/issues/21852#note-7 -- https://bugs.ruby-lang.org/

3 9

[ruby-core:124955] [Ruby Misc#21948] benchmark gem maintainer
by Eregon (Benoit Daloze) 17 Apr '26

17 Apr '26

Issue #21948 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21948: benchmark gem maintainer https://bugs.ruby-lang.org/issues/21948 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I would like to propose myself as maintainer of [benchmark](https://github.com/ruby/benchmark). I always had an interest about the `benchmark` stdlib and did significant contributions to it, notably [979ec8d](https://github.com/ruby/ruby/commit/979ec8df5daf6db314b2f17e53b53d…. @matz approved it [here](https://github.com/ruby/ruby/pull/15424#issuecomment-3640875676), so this issue is mostly for awareness. -- 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