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

[ruby-core:121136] [Ruby master Bug#21151] IO and StringIO raise FrozenError even for read-only methods
by headius (Charles Nutter) 11 Aug '25

11 Aug '25

Issue #21151 has been reported by headius (Charles Nutter). ---------------------------------------- Bug #21151: IO and StringIO raise FrozenError even for read-only methods https://bugs.ruby-lang.org/issues/21151 * Author: headius (Charles Nutter) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Problem -------- While fixing a small [regression](https://github.com/ruby/stringio/issues/119) from my recent StringIO [fixes](https://github.com/ruby/stringio/issues/116) I discovered that a large number of read-only methods will fail if the StringIO is frozen. A few examples: ``` $ ruby -rstringio -e 's = StringIO.new; p s.lineno; s.freeze; p s.lineno' 0 -e:1:in 'StringIO#lineno': can't modify frozen StringIO: #<StringIO:0x0000000103711ea8> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.closed?; s.freeze; p s.closed?' false -e:1:in 'StringIO#closed?': can't modify frozen StringIO: #<StringIO:0x00000001008c1e68> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.eof?; s.freeze; p s.eof?' true -e:1:in 'StringIO#eof?': can't modify frozen StringIO: #<StringIO:0x000000011c171e80> (FrozenError) from -e:1:in '<main>' $ ruby -rstringio -e 's = StringIO.new; p s.pos; s.freeze; p s.pos' 0 -e:1:in 'StringIO#pos': can't modify frozen StringIO: #<StringIO:0x0000000105551df0> (FrozenError) from -e:1:in '<main>' ``` @kou pointed out that IO also raises for at least `lineno` and suggested I re-open the issue here. I still believe these read-only operations should be allowed on frozen IO or StringIO. Cause in StringIO ----------------- This is because the `StringIO` macro calls `get_strio` which calls `rb_io_taint_check` which calls `rb_check_frozen`. The `StringIO` macro is used in almost every method to access the rb_stringio_t data structure. A list of methods I believe should be operable when the StringIO is frozen (in stringio.c definition order): * string (returns underlying String but does not mutate anything) * lineno * pos * closed?/closed_read?/closed_write? * eof/eof? * sync * pid (a dummy method but it writes nothing) * fileno (dummy) * pread (by definition does not modify state) * isatty/tty? * size/length * external_encoding * internal_encoding In addition, `initialize_copy` probably should not require the original StringIO to be writable: ``` $ ruby -rstringio -e 's = StringIO.new("foo"); s.freeze; p s.dup' -e:1:in 'StringIO#initialize_copy': can't modify frozen StringIO: #<StringIO:0x0000000102eb1df8> (FrozenError) from -e:1:in 'Kernel#initialize_dup' from -e:1:in 'Kernel#dup' from -e:1:in '<main>' ``` The data from the original StringIO is unmodified by `initialize_copy`, other than the reference-counting `ptr->count` (which should not be subject to frozen checks). Cause in IO ----------- The `GetOpenFile` macro calls `RB_IO_POINTER` macro which calls `rb_io_taint_check` which calls `rb_check_frozen`. Methods in IO that should work on a frozen IO include any of the above StringIO that currently raise. For example `lineno` uses `GetOpenFile`, but `fileno` does not and does not raise. There's clearly some inconsistency here we can clean up. Origin ------ I believe most of the StringIO cases are caused by this change from 2011 that added frozen checks to StringIO (the class and the macro): https://github.com/ruby/ruby/commit/d8d9bac5c8b071135e50ad3f21c8a9b6a9c06e54 In IO, this behavior dates way back to 2000 by @matz himself: https://github.com/ruby/ruby/commit/087c83d7ceed6893afff93066937fb570ae4a115 Notes ----- I have started to fix the StringIO cases for JRuby in https://github.com/ruby/stringio/pull/122. I could probably fix the C version of StringIO as well, but I'm a little more unsure about how to fix IO. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:122948] [Ruby Feature#17316] On memoization
by marksiemers (Mark Siemers) 11 Aug '25

11 Aug '25

Issue #17316 has been updated by marksiemers (Mark Siemers). I agree with Sebastian that an operator is the best way to keep this code elegant. My proposal is to: **Introduce a new operator `@||` that does instance variable aware memoization succinctly** ```ruby # Allow this syntax def result @result @||= expensive_calculation end # As functionally equivalent to this def result if instance_variable_defined?(:@result) @result else @result = expensive_calculation end end ``` Reasons for this suggestion: 1. `@|` is already not valid syntax, so there should not be any issue with breaking legacy code 2. Use of the `@` symbol is a strong indicator that this impacts and is useful for instance variables 3. Keeping the `||` as part of the operator is familiar syntax for memoization 4. It is succinct, keeps things on one line, adds only one character, does not require blocks or method calls on separate lines (e.g. `memoize(:result)`) 5. If searching for memoization in the codebase - searching for `||=` will still work --- A big motivation for this comes from a recent change to rubocop-rails, which is now enforcing "Rails/FindByOrAssignmentMemoization" (see: https://rails.rubystyle.guide/\#find-by-memoization) A more rails-specific example below of this proposal: ```ruby # Previously allowed (though not performant in the case of nil returned by find_by def foo @foo ||= Foo.find_by(id:) end # The new rule enforces this syntax def foo if instance_variable_defined?(:@foo) @foo else @foo = Foo.find_by(id:) end end ``` Here's my main proposal with some reasons behind it: ```ruby def foo @foo @||= Foo.find_by(id:) end ``` --- Here are some other ideas, but I don't think any of them are as good as `@||`: ```ruby @result |||= expensive_calculation @result -||= expensive_calculation @result +||= expensive_calculation @result _||= expensive_calculation @result &||= expensive_calculation @result %||= expensive_calculation ``` ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114252 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

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

10 Aug '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/

21 74

[ruby-core:122939] [Ruby Bug#21536] ERROR: Error installing tk:
by sevkme (sevk kk) 09 Aug '25

09 Aug '25

Issue #21536 has been reported by sevkme (sevk kk). ---------------------------------------- Bug #21536: ERROR: Error installing tk: https://bugs.ruby-lang.org/issues/21536 * Author: sevkme (sevk kk) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +YJIT +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` shell kkar4 :: ~ » pacman -Ss tcl | grep install extra/tcl 8.6.16-1 [installed] extra/tk 8.6.16-1 [installed] ``` ``` shell kkar4 :: ~ » CFLAGS="-Wold-style-definition" gem install tk Building native extensions. This could take a while... ERROR: Error installing tk: ERROR: Failed to build gem native extension. current directory: /usr/lib/ruby/gems/3.4.0/gems/tk-0.5.1/ext/tk /usr/bin/ruby extconf.rb check functions.checking for ruby_native_thread_p() in ruby.h... yes checking for rb_errinfo() in ruby.h... yes checking for rb_hash_lookup() in ruby.h... yes checking for rb_proc_new() in ruby.h... yes checking for rb_sourcefile() in ruby.h... yes checking for rb_thread_alive_p() in ruby.h... no checking for rb_thread_check_trap_pending() in ruby.h... yes checking for ruby_enc_find_basename() in ruby.h... yes check libraries.checking for t_open() in -lnsl... no checking for socket() in -lsocket... no checking for dlopen() in -ldl... yes checking for log() in -lm... yes Use ActiveTcl libraries (if available). Search tclConfig.sh and tkConfig.sh. Valid [tclConfig.sh, tkConfig.sh] are found in [["/usr/lib", "/usr/lib"], ["/usr/lib64", "/usr/lib64"]] Use [tclConfig.sh, tkConfig.sh] == ["/usr/lib/tclConfig.sh", "/usr/lib/tkConfig.sh"] Use X11 libraries (or use TK_XINCLUDES/TK_XLIBSW information on tkConfig.sh). checking for XOpenDisplay() in -lX11... yes creating Makefile Find Tcl/Tk libraries. Make tcltklib.so which is required by Ruby/Tk. current directory: /usr/lib/ruby/gems/3.4.0/gems/tk-0.5.1/ext/tk make DESTDIR\= sitearchdir\=./.gem.20250809-2512403-8d3buu sitelibdir\=./.gem.20250809-2512403-8d3buu clean current directory: /usr/lib/ruby/gems/3.4.0/gems/tk-0.5.1/ext/tk make DESTDIR\= sitearchdir\=./.gem.20250809-2512403-8d3buu sitelibdir\=./.gem.20250809-2512403-8d3buu compiling stubs.c stubs.c: In function '_nativethread_consistency_check': stubs.c:42:1: warning: old-style function definition [-Wold-style-definition] 42 | _nativethread_consistency_check(ip) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compiling tcltklib.c tcltklib.c: In function 'get_ip': tcltklib.c:784:1: warning: old-style function definition [-Wold-style-definition] 784 | get_ip(self) | ^~~~~~ tcltklib.c: In function 'deleted_ip': tcltklib.c:802:1: warning: old-style function definition [-Wold-style-definition] 802 | deleted_ip(ptr) | ^~~~~~~~~~ tcltklib.c: In function 'rbtk_preserve_ip': tcltklib.c:818:1: warning: old-style function definition [-Wold-style-definition] 818 | rbtk_preserve_ip(ptr) | ^~~~~~~~~~~~~~~~ tcltklib.c: In function 'rbtk_release_ip': tcltklib.c:832:1: warning: old-style function definition [-Wold-style-definition] 832 | rbtk_release_ip(ptr) | ^~~~~~~~~~~~~~~ tcltklib.c: In function 'tcltkip_init_tk': tcltklib.c:1327:1: warning: old-style function definition [-Wold-style-definition] 1327 | tcltkip_init_tk(interp) | ^~~~~~~~~~~~~~~ tcltklib.c: In function 'pending_exception_check1': tcltklib.c:1435:1: warning: old-style function definition [-Wold-style-definition] 1435 | pending_exception_check1(thr_crit_bup, ptr) | ^~~~~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'call_original_exit': tcltklib.c:1480:1: warning: old-style function definition [-Wold-style-definition] 1480 | call_original_exit(ptr, state) | ^~~~~~~~~~~~~~~~~~ tcltklib.c: In function '_timer_for_tcl': tcltklib.c:1631:1: warning: old-style function definition [-Wold-style-definition] 1631 | _timer_for_tcl(clientData) | ^~~~~~~~~~~~~~ tcltklib.c: In function 'set_eventloop_window_mode': tcltklib.c:1682:1: warning: old-style function definition [-Wold-style-definition] 1682 | set_eventloop_window_mode(self, mode) | ^~~~~~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'get_eventloop_window_mode': tcltklib.c:1697:1: warning: old-style function definition [-Wold-style-definition] 1697 | get_eventloop_window_mode(self) | ^~~~~~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'set_eventloop_tick': tcltklib.c:1708:1: warning: old-style function definition [-Wold-style-definition] 1708 | set_eventloop_tick(self, tick) | ^~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'get_eventloop_tick': tcltklib.c:1742:1: warning: old-style function definition [-Wold-style-definition] 1742 | get_eventloop_tick(self) | ^~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'ip_set_eventloop_tick': tcltklib.c:1749:1: warning: old-style function definition [-Wold-style-definition] 1749 | ip_set_eventloop_tick(self, tick) | ^~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'ip_get_eventloop_tick': tcltklib.c:1768:1: warning: old-style function definition [-Wold-style-definition] 1768 | ip_get_eventloop_tick(self) | ^~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'set_no_event_wait': tcltklib.c:1775:1: warning: old-style function definition [-Wold-style-definition] 1775 | set_no_event_wait(self, wait) | ^~~~~~~~~~~~~~~~~ tcltklib.c: In function 'get_no_event_wait': tcltklib.c:1793:1: warning: old-style function definition [-Wold-style-definition] 1793 | get_no_event_wait(self) | ^~~~~~~~~~~~~~~~~ tcltklib.c: In function 'ip_set_no_event_wait': tcltklib.c:1800:1: warning: old-style function definition [-Wold-style-definition] 1800 | ip_set_no_event_wait(self, wait) | ^~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'ip_get_no_event_wait': tcltklib.c:1819:1: warning: old-style function definition [-Wold-style-definition] 1819 | ip_get_no_event_wait(self) | ^~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'set_eventloop_weight': tcltklib.c:1826:1: warning: old-style function definition [-Wold-style-definition] 1826 | set_eventloop_weight(self, loop_max, no_event) | ^~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'get_eventloop_weight': tcltklib.c:1846:1: warning: old-style function definition [-Wold-style-definition] 1846 | get_eventloop_weight(self) | ^~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'ip_set_eventloop_weight': tcltklib.c:1853:1: warning: old-style function definition [-Wold-style-definition] 1853 | ip_set_eventloop_weight(self, loop_max, no_event) | ^~~~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'ip_get_eventloop_weight': tcltklib.c:1873:1: warning: old-style function definition [-Wold-style-definition] 1873 | ip_get_eventloop_weight(self) | ^~~~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'set_max_block_time': tcltklib.c:1880:1: warning: old-style function definition [-Wold-style-definition] 1880 | set_max_block_time(self, time) | ^~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'lib_evloop_thread_p': tcltklib.c:1913:1: warning: old-style function definition [-Wold-style-definition] 1913 | lib_evloop_thread_p(self) | ^~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'lib_evloop_abort_on_exc': tcltklib.c:1926:1: warning: old-style function definition [-Wold-style-definition] 1926 | lib_evloop_abort_on_exc(self) | ^~~~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'ip_evloop_abort_on_exc': tcltklib.c:1939:1: warning: old-style function definition [-Wold-style-definition] 1939 | ip_evloop_abort_on_exc(self) | ^~~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'lib_evloop_abort_on_exc_set': tcltklib.c:1946:1: warning: old-style function definition [-Wold-style-definition] 1946 | lib_evloop_abort_on_exc_set(self, val) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'ip_evloop_abort_on_exc_set': tcltklib.c:1960:1: warning: old-style function definition [-Wold-style-definition] 1960 | ip_evloop_abort_on_exc_set(self, val) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'lib_num_of_mainwindows_core': tcltklib.c:1979:1: warning: old-style function definition [-Wold-style-definition] 1979 | lib_num_of_mainwindows_core(self, argc, argv) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'lib_num_of_mainwindows': tcltklib.c:1992:1: warning: old-style function definition [-Wold-style-definition] 1992 | lib_num_of_mainwindows(self) | ^~~~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'call_DoOneEvent': tcltklib.c:2045:21: error: passing argument 1 of 'tk_funcall' from incompatible pointer type [-Wincompatible-pointer-types] 2045 | return tk_funcall(call_DoOneEvent_core, 0, (VALUE*)NULL, flag_val); | ^~~~~~~~~~~~~~~~~~~~ | | | VALUE (*)(VALUE) {aka long unsigned int (*)(long unsigned int)} In file included from /usr/include/ruby-3.4.0/ruby/defines.h:77, from /usr/include/ruby-3.4.0/ruby/ruby.h:25, from /usr/include/ruby-3.4.0/ruby.h:38, from tcltklib.c:10: tcltklib.c:258:28: note: expected 'VALUE (*)(void)' {aka 'long unsigned int (*)(void)'} but argument is of type 'VALUE (*)(VALUE)' {aka 'long unsigned int (*)(long unsigned int)'} 258 | static VALUE tk_funcall _((VALUE(), int, VALUE*, VALUE)); | ^~~~~~~ /usr/include/ruby-3.4.0/ruby/backward/2/stdarg.h:33:18: note: in definition of macro '_' 33 | # define _(args) args | ^~~~ tcltklib.c:2021:1: note: 'call_DoOneEvent_core' declared here 2021 | call_DoOneEvent_core(VALUE flag_val) | ^~~~~~~~~~~~~~~~~~~~ tcltklib.c: In function 'lib_eventloop_core': tcltklib.c:2197:1: warning: old-style function definition [-Wold-style-definition] 2197 | lib_eventloop_core(check_root, update_flag, check_var, interp) | ^~~~~~~~~~~~~~~~~~ ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122915] [Ruby Bug#21531] /usr/src/ruby/vm_insnhelper.c:131: Assertion Failed: callable_method_entry_p:IMEMO_TYPE_P((VALUE)cme, imemo_ment): imemo_type:env
by yahonda (Yasuo Honda) 07 Aug '25

07 Aug '25

Issue #21531 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #21531: /usr/src/ruby/vm_insnhelper.c:131: Assertion Failed: callable_method_entry_p:IMEMO_TYPE_P((VALUE)cme, imemo_ment): imemo_type:env https://bugs.ruby-lang.org/issues/21531 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: 3.5.0p-1 (2025-08-02 revision fca2e6f8f53920170654e696c2585fcd3f4ebe11) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Rails CI is consistently throwing assertion failures, but I can't replicate this behavior locally yet. https://buildkite.com/rails/rails-nightly/builds/2619#0198676f-b98c-4c4e-a6… ``` /usr/local/bin/ruby -w -I"lib:test" /usr/local/lib/ruby/gems/3.5.0+2/gems/rake-13.3.0/lib/rake/rake_test_loader.rb "test/activejob/destroy_association_async_job_test.rb" "test/activejob/destroy_association_async_test.rb" "test/activejob/job_checkpoints_test.rb" "test/activejob/job_runtime_test.rb" --profile /usr/local/lib/ruby/gems/3.5.0+2/gems/i18n-1.14.7/lib/i18n/exceptions.rb:3: warning: CGI library is removed from Ruby 3.5. Please use cgi/escape instead for CGI.escape and CGI.unescape features. If you need to use the full features of CGI library, Please install cgi gem. /usr/src/ruby/vm_insnhelper.c:131: Assertion Failed: callable_method_entry_p:IMEMO_TYPE_P((VALUE)cme, imemo_ment): imemo_type:env ruby 3.5.0dev (2025-08-01T16:00:05Z master fca2e6f8f5) +PRISM [x86_64-linux] ``` ### Environment - Using rubylang/ruby:master-debug Docker image provided via https://hub.docker.com/r/rubylang/ruby/ - Last successful build with Ruby 3.5.0p-1 (2025-08-01 revision b3598cf2a355497693bb66097edc156af3152e9b) [x86_64-linux] https://buildkite.com/rails/rails-nightly/builds/2614#01986249-5d8f-4315-ba… - I suspect this problem was introduced by one of the commits in this range: https://github.com/ruby/ruby/compare/b3598cf2a355497693bb66097edc156af3152e… -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111789] [Ruby master Feature#19333] Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks.
by ioquatix (Samuel Williams) 07 Aug '25

07 Aug '25

Issue #19333 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19333: Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks. https://bugs.ruby-lang.org/issues/19333 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As it stands, Fiber Locals, Thread Locals and Fiber Storage have no way of deleting key-value associations. ```ruby 100.times do |i| name = :"variable-#{i}" Thread.current[name] = 10 end ``` Because of this, dynamically generated associations can leak over time. This is worse for things like Threads that might be pooled (or maybe an argument against user-space pooling). In any case, having a way to delete those associations would allow application code to at least delete the associations when they no longer make sense. I propose that assigning `nil` to "locals" or "storage" should effectively delete them. e.g. ```ruby 100.times do |i| name = :"variable-#{i}" Thread.current[name] = 10 Thread.current[name] = nil # delete association end ``` A more invasive alternative would be to define new interfaces like `Thread::Local`, `Fiber::Local` and `Fiber::Storage::Local` (or something) which correctly clean up on GC. -- https://bugs.ruby-lang.org/

3 9

[ruby-core:114590] [Ruby master Bug#19857] Eval coverage is reset after each `eval`.
by ioquatix (Samuel Williams) 06 Aug '25

06 Aug '25

Issue #19857 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19857: Eval coverage is reset after each `eval`. https://bugs.ruby-lang.org/issues/19857 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- It seems like `eval` based coverage is reset every time eval is invoked. ```ruby #!/usr/bin/env ruby require 'coverage' def measure(flag) c = Class.new c.class_eval(<<~RUBY, "foo.rb", 1) def foo(flag) if flag puts "foo" else puts "bar" end end RUBY return c.new.foo(flag) end Coverage.start(lines: true, eval: true) # Depending on the order of these two operations, different computation is calculated, because the evaluation of the code is considered different, even if the content/path is the same. measure(false) measure(true) p Coverage.result ``` Further investigation is required. -- https://bugs.ruby-lang.org/

4 20

[ruby-core:121054] [Ruby master Bug#21139] Prism and parse.y parses `it = it` differently
by tompng (tomoya ishida) 05 Aug '25

05 Aug '25

Issue #21139 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21139: Prism and parse.y parses `it = it` differently https://bugs.ruby-lang.org/issues/21139 * Author: tompng (tomoya ishida) * Status: Assigned * Assignee: prism * ruby -v: ruby 3.5.0dev (2025-02-14T16:49:52Z master ee181d1bb7) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ # ruby --parser=parse.y -e "42.tap { it = it; p it }" nil # ruby --parser=prism -e "42.tap { it = it; p it }" 42 ~~~ -- https://bugs.ruby-lang.org/

12 18

[ruby-core:122910] [Ruby Bug#21530] Is IO#eof? supposed to always block and read?
by tenderlovemaking (Aaron Patterson) 05 Aug '25

05 Aug '25

Issue #21530 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21530: Is IO#eof? supposed to always block and read? https://bugs.ruby-lang.org/issues/21530 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I'm not sure whether or not this is expected behavior, but it seems like eof? blocks when called on $stdin. For example: ```ruby if (str = $stdin.gets) $stderr.puts "read #{str}" end if $stdin.eof? # this call waits for input $stderr.puts "stdin is eof" end ``` I think this is kind of odd behavior because if you input a string but _do not_ input a newline, then hit ^D twice, `$stdin` should be at EOF, but `eof?` will block and wait for input. If you hit ^D a third time, $stdin will be EOF, but if you input a different character it will not be EOF. Compare this C program: ```c #include <stdio.h> #include <stdlib.h> #define BUF_SIZE 4096 int main(int argc, char *argv[]) { char buf[BUF_SIZE]; if (fgets(buf, BUF_SIZE, stdin)) { fprintf(stderr, "read %s\n", buf); } if (feof(stdin)) { // Does not block fprintf(stderr, "stdin is EOF\n"); } } ``` If you hit ^D twice with this C program, `feof` will return true for `stdin`. I would have expected the Ruby program and the C program to behave similarly, but they don't. Is this expected? The documentation indeed says that `eof?` will read, but shouldn't the IO be at EOF after the second ^D? Thank you. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122817] [Ruby Bug#21517] Behaviour of StringIO#readpartial with multibyte differs from IO#readpartial
by herwin (Herwin W) 03 Aug '25

03 Aug '25

Issue #21517 has been reported by herwin (Herwin W). ---------------------------------------- Bug #21517: Behaviour of StringIO#readpartial with multibyte differs from IO#readpartial https://bugs.ruby-lang.org/issues/21517 * Author: herwin (Herwin W) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [x86_64-linux] (+ others) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The specs for `IO#readpartial` have the following test (https://github.com/ruby/spec/blob/ed254bae321221f5cd24280beb37e5bddaff6bb6/…) ```ruby before :each do @rd, @wr = IO.pipe @rd.binmode @wr.binmode end it "reads after ungetc with multibyte characters in the buffer" do @wr.write("∂φ/∂x = gaîté") c = @rd.getc @rd.ungetc(c) @rd.readpartial(3).should == "\xE2\x88\x82" @rd.readpartial(3).should == "\xCF\x86/" end ``` This behaviour is different in `StringIO#readpartial`. If I add this as a spec: ```ruby it "reads after ungetc with multibyte characters in the buffer" do @string = StringIO.new(+"∂φ/∂x = gaîté") c = @string.getc @string.ungetc(c) @string.readpartial(3).should == "\xE2\x88\x82" @string.readpartial(3).should == "\xCF\x86/" end ``` it fails with every supported Ruby version, and even with 3.5-dev of today, with the message `Expected "\xE2\x88\x82" == "∂"` The `getc` + `ungetc` can be removed, but this does not change the behaviour. -- https://bugs.ruby-lang.org/

1 2