August 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:119998] [Ruby master Bug#20907] Fiber scheduler does not correctly re-lock mutex if `Mutex#sleep` is interrupted.
by ioquatix (Samuel Williams) 17 Nov '25

17 Nov '25

Issue #20907 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20907: Fiber scheduler does not correctly re-lock mutex if `Mutex#sleep` is interrupted. https://bugs.ruby-lang.org/issues/20907 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- The following test fails with a `ThreadError` instead of a `RuntimeError`: ```ruby def test_condition_variable condition_variable = ::Thread::ConditionVariable.new mutex = ::Thread::Mutex.new error = nil thread = Thread.new do Thread.current.report_on_exception = false scheduler = Scheduler.new Fiber.set_scheduler scheduler fiber = Fiber.schedule do begin mutex.synchronize do condition_variable.wait(mutex) end rescue => error end end fiber.raise(RuntimeError) end thread.join assert_kind_of RuntimeError, error end ``` Fix: https://github.com/ruby/ruby/pull/12158 -- https://bugs.ruby-lang.org/

3 3

[ruby-core:121688] [Ruby Feature#21275] Update to Unicode 17.0
by duerst 14 Nov '25

14 Nov '25

Issue #21275 has been reported by duerst (Martin Dürst). ---------------------------------------- Feature #21275: Update to Unicode 17.0 https://bugs.ruby-lang.org/issues/21275 * Author: duerst (Martin Dürst) * Status: Open * Assignee: duerst (Martin Dürst) * Target version: 3.5 ---------------------------------------- Unicode 17.0 is currently in alpha. Beta is planned for late May, release for September 2025. We just updated to Unicode 16.0, so we can start testing with alpha/beta. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119895] [Ruby master Bug#20889] IO#ungetc and IO#ungetbyte should not cause IO#pos to report an inaccurate position
by javanthropus (Jeremy Bopp) 13 Nov '25

13 Nov '25

Issue #20889 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20889: IO#ungetc and IO#ungetbyte should not cause IO#pos to report an inaccurate position https://bugs.ruby-lang.org/issues/20889 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8') do |f| f.write('0123456789') f.rewind f.ungetbyte(93) f.pos # => -1; negative value is surprising! end Tempfile.open(encoding: 'utf-8') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-8')) f.pos # => -1; similar to the ungetbyte case end Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-16le')) f.pos # => 0; maybe should be -2 to match the previous ungetc case? end ``` It doesn't seem logical that `IO#pos` should ever be affected by `IO#ungetc` or `IO#ungetbyte`. The pushed characters or bytes aren't really in the stream source. The value of `IO#pos` implies that jumping directly to that position via `IO#seek` and reading from there would return the same character or byte that was pushed, but the pushed characters or bytes are lost when the operation to seek in the stream is performed. In the case where `IO#pos` is a negative value, attempting to seek to that position actually raises an exception. In the `IO#ungetc` with character conversion case above, it seems unreasonable to make `IO#pos` report an even less correct position. In that case, the position would need to be adjusted by 2 bytes in reverse due to the internal encoding of the stream, but that is completely inconsistent with the behavior of `IO#pos` when reading from the stream normally where it reports the underlying stream's byte position and not the number of transcoded bytes that have been read: ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.getc.bytesize # => 2; due to the internal encoding of the stream f.pos # => 1; reports actual bytes read from the stream, not transcoded bytes end ``` Attempting to use `IO#pos` when there are characters or bytes pushed into the read buffer by way of `IO#ungetc` or `IO#ungetbyte` should result in one of the following behaviors: 1. Raise and exception 2. Return the stream's position, clearing the read buffer entirely 3. Return the stream's position, ignoring the pushed characters or bytes, and produce a warning -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122773] [Ruby Feature#21513] Raise on converting endless range to set
by viralpraxis (Iaroslav Kurbatov) 13 Nov '25

13 Nov '25

Issue #21513 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Feature #21513: Raise on converting endless range to set https://bugs.ruby-lang.org/issues/21513 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open ---------------------------------------- Converting endless range to array raises: ``` shell ruby -e '(1..).to_a' -e:1:in 'Range#to_a': cannot convert endless range to an array (RangeError) from -e:1:in '<main>' ``` but converting to set does not: ``` shell ruby -e '(1..).to_set # hangs' ``` I think it makes to raise in both cases for consistency. Something like this should do the trick: ``` diff diff --git i/prelude.rb w/prelude.rb index f49cada637..11bfa3fc95 100644 --- i/prelude.rb +++ w/prelude.rb @@ -30,6 +30,10 @@ module Enumerable # Makes a set from the enumerable object with given arguments. # Passing arguments to this method is deprecated. def to_set(*args, &block) + if self.class == Range && self.end.nil? + raise RangeError, "cannot convert endless range to a set" + end + klass = if args.empty? Set else diff --git i/test/ruby/test_range.rb w/test/ruby/test_range.rb index f875c0ab40..27b968641b 100644 --- i/test/ruby/test_range.rb +++ w/test/ruby/test_range.rb @@ -1541,4 +1541,11 @@ def test_overlap? assert_not_operator((1...3), :overlap?, (3..4)) assert_not_operator((...3), :overlap?, (3..)) end + + def test_to_set + assert_equal(Set[], (1..-1).to_set) + assert_equal(Set[1, 2, 3], (1..3).to_set) + + assert_raise(RangeError) { (239..).to_set } + end end ``` If this patch is accepted, I'll open a PR. ``` shell ./ruby -v ruby 3.5.0dev (2025-07-14T20:34:32Z master a6d483971a) +PRISM [x86_64-linux] ``` -- https://bugs.ruby-lang.org/

5 7

[ruby-core:122343] [Ruby Misc#21385] Namespace: Suggesting a rename
by fxn (Xavier Noria) 11 Nov '25

11 Nov '25

Issue #21385 has been reported by fxn (Xavier Noria). ---------------------------------------- Misc #21385: Namespace: Suggesting a rename https://bugs.ruby-lang.org/issues/21385 * Author: fxn (Xavier Noria) * Status: Open ---------------------------------------- I'd like to suggest a rename of namespaces. The word "namespace" is already taken in Ruby. We say that classes and modules act as or represent. Constant paths nest them in practice. We say that it is a best practice that gems create their own namespace, etc. If the feature goes ahead with this name, the above sentences, well-established in the Ruby community, will start to sound confusing, because that meaning of "namespace" stays. If you look at the index in Matz's book, "namespaces" is indexed in pages 248–250. Title of section 7.5.1 is "Modules as Namespaces". Besides, I have had a few experiences explaining the proposal to people, and quickly realizing they assume this is something like C++ namespaces or Java packages. Then, I have to undo that mental model and start all over saying "forget that mental model". Those are like our constant paths, only more simple and strict. I think it may also be confusing in this sense (though this could be OK if it wasn't for the previous point.) To be constructive: Some alternative names that I have thought about are "isolates", "shields", or "cells". ("sandboxes" is close, but may have security connotations you do not want to suggest.) -- https://bugs.ruby-lang.org/

18 32

[ruby-core:117434] [Ruby master Bug#20409] Missing reporting some invalid breaks
by kddnewton (Kevin Newton) 06 Nov '25

06 Nov '25

Issue #20409 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20409: Missing reporting some invalid breaks https://bugs.ruby-lang.org/issues/20409 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- -- https://bugs.ruby-lang.org/

3 7

[ruby-core:123146] [Ruby Bug#21559] Unicode normalization nfd -> nfc -> nfd is not reversible
by tompng (tomoya ishida) 03 Nov '25

03 Nov '25

Issue #21559 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21559: Unicode normalization nfd -> nfc -> nfd is not reversible https://bugs.ruby-lang.org/issues/21559 * Author: tompng (tomoya ishida) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I expect `nfd(nfc(str)) == nfd(str)` but found a string that doesn't. ~~~ruby # Ruby 3.1 - 3.5 str = "s\u{11930}\u{323}\u{11930}\u{307}" p str.unicode_normalize(:nfd) == str.unicode_normalize(:nfc).unicode_normalize(:nfd) #=> false ~~~ ~~~ruby # ruby 3.5.0dev str = "s\u{1611e}\u{323}\u{1611e}\u{307}\u{1611f}" p str.unicode_normalize(:nfd) == str.unicode_normalize(:nfc).unicode_normalize(:nfd) #=> false ~~~ -- https://bugs.ruby-lang.org/

4 7

[ruby-core:116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default
by byroot (Jean Boussier) 28 Oct '25

28 Oct '25

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/

22 76

[ruby-core:122883] [Ruby Bug#21522] Accessing outer locals via eval in a Ractor returns false
by tenderlovemaking (Aaron Patterson) 24 Oct '25

24 Oct '25

Issue #21522 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21522: Accessing outer locals via eval in a Ractor returns false https://bugs.ruby-lang.org/issues/21522 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Assignee: ractor * ruby -v: ruby 3.5.0dev (2025-07-28T22:17:45Z master f1acf47ca2) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Normally, if you try to access a local that's been defined outside the scope of the Ractor block, it'll raise an ArgumentError. However, if you try to access the local via `eval` it will return the value `false`. ```ruby foo = Object.new begin Ractor.new { p foo }.value rescue ArgumentError end Ractor.new { p eval("foo") # => false }.value ``` I'm not sure how we fix this, since my guess is that we zero the environment when copying, but I wanted to file the issue so we can track it. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:116083] [Ruby master Feature#20163] Introduce #bit_count method on Integer
by garrison (Garrison Jensen) 24 Oct '25

24 Oct '25

Issue #20163 has been reported by garrison (Garrison Jensen). ---------------------------------------- Feature #20163: Introduce #bit_count method on Integer https://bugs.ruby-lang.org/issues/20163 * Author: garrison (Garrison Jensen) * Status: Open * Priority: Normal ---------------------------------------- This feature request is to implement a method called #bit_count on Integer that returns the number of ones in the binary representation of the absolute value of the integer. ``` n = 19 n.bit_count #=> 3 (-n).bit_count #=> 3 ``` This is often useful when you use an integer as a bitmask and want to count how many bits are set. This would be equivalent to ``` n.to_s(2).count("1") ``` However, this can be outperformed by ``` def bit_count(n) count = 0 while n > 0 n &= n - 1 # Flip the least significant 1 bit to 0 count += 1 end count end ``` I think this would be a useful addition because it would fit alongside the other bit-related methods defined on integer: `#bit_length,` `#allbits?`, `#anybits?`, `#nobits?`. Also, when working with bitmasks, a minor upgrade to performance often results in a significant improvement. Similar methods from other languages: https://docs.python.org/3/library/stdtypes.html#int.bit_count https://doc.rust-lang.org/std/primitive.i32.html#method.count_ones -- https://bugs.ruby-lang.org/

13 24