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

[ruby-core:123474] [Ruby Feature#21637] Tracing global variable assignment
by viralpraxis (Iaroslav Kurbatov) 11 Nov '25

11 Nov '25

Issue #21637 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Feature #21637: Tracing global variable assignment https://bugs.ruby-lang.org/issues/21637 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open ---------------------------------------- ## Motivation Currently, there is no straightforward way to track global variable assignments at runtime. The only workaround I am aware of involves using the `line` TracePoint event, combined with manipulation of the source code's AST, but this approach is extremely slow and impractical. I'd like to propose a new `gvar_set` (and probably `gvar_get`, but that's out of the scope of this ticket) event which would fire whenever a global variable is written to. ## Context There's current an open https://bugs.ruby-lang.org/issues/15854 feature request with a PR by @st0012, but they currently do not address the global variables, so I've decided to open a new one and a new PR. There's an open gvar-specific question: should "system" global variables like `$!` trigger the `gvar_set` event? (the current implementation does not) ## Usage example ```ruby # frozen-string-literal: true TracePoint.new(:gvar_set) { p [it.gvar_name, it.return_value] }.enable do $G1 = 1 $G2 = 2 $G3 = 3 end # [:$G1, 1] # [:$G2, 2] # [:$G3, 3] ``` -- https://bugs.ruby-lang.org/

3 3

[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:123746] [Ruby Bug#21677] Integer("08") raises an ArgumentError
by ben 10 Nov '25

10 Nov '25

Issue #21677 has been reported by ben (Björn Engelmann). ---------------------------------------- Bug #21677: Integer("08") raises an ArgumentError https://bugs.ruby-lang.org/issues/21677 * Author: ben (Björn Engelmann) * Status: Open * ruby -v: 3.3.0 - 3.3.8 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ruby version: tried it with 3.3.0 and 3.3.8 When running the following ruby script: p Integer("04") p Integer("05") p Integer("06") p Integer("07") p Integer("08") I get the following output: 4 5 6 7 <internal:kernel>:307:in `Integer': invalid value for Integer(): "08" (ArgumentError) from bug.rb:7:in `<main>' it seems that "08" and "09" are for some reason not parsable, while all other number "00", "01", "02", "03", "04", "05", "06", and "07" are. I would have expected the Integer-parser to have consistent behaviour, independent of the numbers that are parsed... By the way: it the same for "008", "0008" and so on. -- https://bugs.ruby-lang.org/

5 4

[ruby-core:123738] [Ruby Bug#21676] make[2]: *** No rule to make target '../../../.././ext/-test-/namespace/yay1/yay1.h', needed by 'yay1.o'. Stop.
by duerst 10 Nov '25

10 Nov '25

Issue #21676 has been reported by duerst (Martin Dürst). ---------------------------------------- Bug #21676: make[2]: *** No rule to make target '../../../.././ext/-test-/namespace/yay1/yay1.h', needed by 'yay1.o'. Stop. https://bugs.ruby-lang.org/issues/21676 * Author: duerst (Martin Dürst) * Status: Open * Target version: 4.0 * ruby -v: ruby 3.5.0dev (2025-11-02T10:22:22Z master bd51b20c50) +PRISM [x86_64-linux] last_commit=minor code allignment (related to bug 21559) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When I tried to compile Ruby with make up; make, I got the message in the Subject. This seems similar to bug #19481, but the various kinds of advice (`./config.status` or `./autogen.sh; ./configure; make`) given there didn't solve the problem. The last part of the output is ``` compiling memory_view.c linking shared-object -test-/memory_view.so make[2]: Leaving directory '/home/duerst/34ruby/ext/-test-/memory_view' make[2]: Entering directory '/home/duerst/34ruby/ext/-test-/method' compiling arity.c compiling init.c linking shared-object -test-/method.so make[2]: Leaving directory '/home/duerst/34ruby/ext/-test-/method' make[2]: Entering directory '/home/duerst/34ruby/ext/-test-/namespace/yay1' make[2]: *** No rule to make target '../../../.././ext/-test-/namespace/yay1/yay1.h', needed by 'yay1.o'. Stop. make[2]: Leaving directory '/home/duerst/34ruby/ext/-test-/namespace/yay1' make[1]: *** [exts.mk:197: ext/-test-/namespace/yay1/all] Error 2 make[1]: Leaving directory '/home/duerst/34ruby' make: *** [uncommon.mk:351: build-ext] Error 2 ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:123595] [Ruby Misc#21657] Question: Is Ruby 4.0 planned for December 2025 or later?
by dmitry.pogrebnoy (Dmitry Pogrebnoy) 10 Nov '25

10 Nov '25

Issue #21657 has been reported by dmitry.pogrebnoy (Dmitry Pogrebnoy). ---------------------------------------- Misc #21657: Question: Is Ruby 4.0 planned for December 2025 or later? https://bugs.ruby-lang.org/issues/21657 * Author: dmitry.pogrebnoy (Dmitry Pogrebnoy) * Status: Open ---------------------------------------- Hello Ruby core team, I noticed that the first preview of Ruby 3.5 has been released, and at the same time there’s some talk in the community about Ruby 4.0 potentially arriving in December 2025. Could you please clarify what the current roadmap looks like? Is Ruby 4.0 already planned for this December, or is the next stable release still Ruby 3.5? Having a clear, public roadmap would really help library and tooling authors (like IDE vendors) prepare for upcoming versions and provide better support. Thank you! -- https://bugs.ruby-lang.org/

10 22

[ruby-core:123678] [Ruby Bug#21668] Backport 6cc66469a007d2fb272397e5e27c20b4ce628f5e
by tompng (tomoya ishida) 08 Nov '25

08 Nov '25

Issue #21668 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21668: Backport 6cc66469a007d2fb272397e5e27c20b4ce628f5e https://bugs.ruby-lang.org/issues/21668 * Author: tompng (tomoya ishida) * Status: Closed * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Improves micro-benchmark of UnicodeNormalize https://github.com/ruby/ruby/pull/14494 ~~~ruby 100000.times{UnicodeNormalize.canonical_ordering_one("s\u0307\u0323")} # 0.107795s → 0.067496s ~~~ -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123717] [Ruby Bug#21671] Rails CI raises `Assertion Failed: rbimpl_rstring_getmem:RB_TYPE_P(str, RUBY_T_STRING): actual type: 26` with "-DENABLE_PATH_CHECK=0 -DRUBY_DEBUG=1" enabled
by yahonda (Yasuo Honda) 08 Nov '25

08 Nov '25

Issue #21671 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #21671: Rails CI raises `Assertion Failed: rbimpl_rstring_getmem:RB_TYPE_P(str, RUBY_T_STRING): actual type: 26` with "-DENABLE_PATH_CHECK=0 -DRUBY_DEBUG=1" enabled https://bugs.ruby-lang.org/issues/21671 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-28T15:44:25Z master 7a736545e9) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Recently Rails CI using "-DENABLE_PATH_CHECK=0 -DRUBY_DEBUG=1" enabled ruby raises `Assertion Failed: rbimpl_rstring_getmem:RB_TYPE_P(str, RUBY_T_STRING): actual type: 26` assertion failures. https://buildkite.com/rails/rails-nightly/builds/3121#019a5af8-b2a1-4289-a7… ### Steps to reproduce 1. Build Ruby with this configure option ``` ./configure --prefix="/home/yahonda/.local/share/mise/installs/ruby/trunk" cppflags="-DENABLE_PATH_CHECK=0 -DRUBY_DEBUG=1" optflags="-O3 -fno-inline" --disable-install-doc ``` 2. Clone Rails repository and run Active Job integration tests ``` git clone https://github.com/rails/rails cd rails/activejob bundle update --bundler bundle install bundle exec rake test:integration ``` ### Expected behavior All of tests should pass. ### Actual behavior It usually raises `./include/ruby/internal/core/rstring.h:391: Assertion Failed: rbimpl_rstring_getmem:RB_TYPE_P(str, RUBY_T_STRING): actual type: 26` I have attached the entire output as assertion_failed.log ---Files-------------------------------- assertion_failed.log (495 KB) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:123389] [Ruby Feature#21625] Allow IO#wait_readable together with IO#ungetc
by YO4 (Yoshinao Muramatsu) 07 Nov '25

07 Nov '25

Issue #21625 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Feature #21625: Allow IO#wait_readable together with IO#ungetc https://bugs.ruby-lang.org/issues/21625 * Author: YO4 (Yoshinao Muramatsu) * Status: Open ---------------------------------------- ### Background IO#wait_readable calles rb_io_check_byte_readable() in that C implementation, so that is treated as binary reading class operation. ```ruby open(IO::NULL, "rt") { |f| f.ungetc(?a); f.wait_readable } # => in 'IO#wait_readable': byte oriented read for character buffered IO (IOError) ``` This is inconsistent with the behavior of IO#select. ```ruby open(IO::NULL, "rt") { |f| f.ungetc(?a); IO.select([f]) } # => [[#<File:NUL (closed)>], [], []] ``` ### Proposal Change IO#wait_readable into character reading class function. This allows mixing usage of IO#wait_readable and IO#ungetc. This change avoids the IOError that previously occurred, but in that case, an exception is thrown when the binary read method is subsequently called. Overall behavior remains unchanged, but exceptions will occur at more desirable locations. If the method being called next is a character method, no exception will be thrown. But that is the desired behavior. ### related methods IO#io_wait_priority may apply similar changes for consistency. IO#ready? seems to have the same issue. This is in the io-wait default gem. IO#wait already respects the character read buffer. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:123477] [Ruby Bug#21638] Ractor-local `$DEBUG` is not marked
by nobu (Nobuyoshi Nakada) 07 Nov '25

07 Nov '25

Issue #21638 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21638: Ractor-local `$DEBUG` is not marked https://bugs.ruby-lang.org/issues/21638 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- https://github.com/sampersand/blog/blob/master/the%20-s%20flag.md#the-segfa… -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123725] [Ruby Bug#13671] Regexp with lookbehind and case-insensitivity raises RegexpError only on strings with certain characters
by alanwu (Alan Wu) 07 Nov '25

07 Nov '25

Issue #13671 has been updated by alanwu (Alan Wu). Backport changed from 3.2: REQUIRED, 3.3: DONE, 3.4: REQUIRED to 3.2: REQUIRED, 3.3: DONE, 3.4: DONE ruby_3_4 commit:3150a1d989d81089c7da7d0491321e370e71f482 ---------------------------------------- Bug #13671: Regexp with lookbehind and case-insensitivity raises RegexpError only on strings with certain characters https://bugs.ruby-lang.org/issues/13671#change-115111 * Author: dschweisguth (Dave Schweisguth) * Status: Closed * Assignee: duerst (Martin Dürst) * ruby -v: 2.4.1 * Backport: 3.2: REQUIRED, 3.3: DONE, 3.4: DONE ---------------------------------------- Here is a test program: ~~~ ruby def test(description) begin yield puts "#{description} is OK" rescue RegexpError puts "#{description} raises RegexpError" end end test("ass, case-insensitive, special") { /(?<!ass)/i =~ '✨' } test("bss, case-insensitive, special") { /(?<!bss)/i =~ '✨' } test("as, case-insensitive, special") { /(?<!as)/i =~ '✨' } test("ss, case-insensitive, special") { /(?<!ss)/i =~ '✨' } test("ass, case-sensitive, special") { /(?<!ass)/ =~ '✨' } test("ass, case-insensitive, regular") { /(?<!ass)/i =~ 'x' } ~~~ Running the test program with Ruby 2.4.1 (macOS) gives ~~~ ass, case-insensitive, special raises RegexpError bss, case-insensitive, special raises RegexpError as, case-insensitive, special is OK ss, case-insensitive, special is OK ass, case-sensitive, special is OK ass, case-insensitive, regular is OK ~~~ The RegexpError is "invalid pattern in look-behind: /(?<!ass)/i (RegexpError)" Side note: in the real code in which I found this error I was able to work around the error by using (?i) after the lookbehind instead of //i. Running the test program with Ruby 2.3.4 does not report any RegexpErrors. I think this is a regression, although I might be wrong and it might be saving me from an incorrect result with certain strings. ---Files-------------------------------- test.rb (531 Bytes) -- https://bugs.ruby-lang.org/

1 0