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

[ruby-core:122724] [Ruby Misc#21508] DevMeeting-2025-08-21
by mame (Yusuke Endoh) 15 Aug '25

15 Aug '25

Issue #21508 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21508: DevMeeting-2025-08-21 https://bugs.ruby-lang.org/issues/21508 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/08/21 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/08/18. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:115438] [Ruby master Misc#20013] Travis CI status
by jaruga (Jun Aruga) 15 Aug '25

15 Aug '25

Issue #20013 has been reported by jaruga (Jun Aruga). ---------------------------------------- Misc #20013: Travis CI status https://bugs.ruby-lang.org/issues/20013 * Author: jaruga (Jun Aruga) * Status: Open * Priority: Normal ---------------------------------------- I would like to use this ticket to manage our activities to report Travis CI status. Because there is Travis CI status page provided by Travis CI. However, even when the page shows ok, I actually see infra issues. https://www.traviscistatus.com/ I would share my activities and report the Travis CI status on the ticket. The ticket's status is not closed until we stop using Travis CI. The easiest option to fix the Travis infra issue is to email Travis CI support `support _AT_ travis-ci.com`. You can check [this ruby/ruby Travis CI wiki page](https://github.com/ruby/ruby/wiki/CI-Servers#travis-ci) for details. -- https://bugs.ruby-lang.org/

2 50

[ruby-core:122968] [Ruby Misc#21544] CI: Launchable: Early flake detection
by ono-max (Naoto Ono) 15 Aug '25

15 Aug '25

Issue #21544 has been reported by ono-max (Naoto Ono). ---------------------------------------- Misc #21544: CI: Launchable: Early flake detection https://bugs.ruby-lang.org/issues/21544 * Author: ono-max (Naoto Ono) * Status: Open ---------------------------------------- I'm a software engineer at Launchable, and I'd like to propose the mechanism to detect potential flaky tests. ## Background In the current Ruby CI, it's easy for flaky tests to be unintentionally merged into the master branch. Even when tests are known to be flaky, they can often be overlooked because re-running them may yield a passing result. Once flaky tests make it into the master branch, they become much harder to debug, and even reverting the changes can be difficult. Therefore, it's crucial to identify potential flaky tests as early as possible—ideally before merging a pull request into the master branch. If we can detect a flaky test during the PR stage, we can prevent it from being introduced into the codebase. ## How it works Here is the basic flow: 1. After the initial run, Launchable provides a list of tests to re-run. 2. The Ruby test framework executes these tests and uploads the results. 3. Using historical data, Launchable detects new or updated tests and returns an updated list. 4. The Ruby test framework runs the new list of tests and uploads the results. 5. Based on these results, Launchable determines which tests need to be re-run. 6. The Ruby test framework executes the identified tests and uploads the results. 7. Repeat step 5 and 6 until Launchable returns an empty test list. Here is the image: <img src="CI_workflow.png" alt="My Image" style="width:600px;"> ## Concerns * How much will Ruby CI slow down with this change? I don't believe this change significantly slow down the CI process. For example, consider a new test that takes 10 seconds to run. Adding 5 seconds to records to record test results to Launchable and another 5 seconds to provide the test list for re-runs, the total time per attempt becomes: (10 sec + 5 sec + 5 sec) = 20 seconds. With 5 retries, the total execution time would be: 20 seconds × 5 = 100 seconds. ---Files-------------------------------- CI_workflow.png (266 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122958] [Ruby Feature#17316] On memoization
by Dan0042 (Daniel DeLorme) 12 Aug '25

12 Aug '25

Issue #17316 has been updated by Dan0042 (Daniel DeLorme). ixti (Alexey Zapparov) wrote in #note-14: > Firstly, rbocop is totally optional. Secondly, even rubocop is suggesting something more elegant than the above example: Ah yes you're right. I read "The new rule enforces this syntax" and took it at face value. But yeah the link has the much more common idiom `return @foo if defined?(@foo)` Also I got the impression this was an official style guide from the Rails team, but now I'm not so sure. Sorry for the overreaction. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114263 * 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:122957] [Ruby Feature#17316] On memoization
by ixti (Alexey Zapparov) 12 Aug '25

12 Aug '25

Issue #17316 has been updated by ixti (Alexey Zapparov). > > ``` > > def foo > > if instance_variable_defined?(:@foo) > > @foo > > else > > @foo = Foo.find_by(id:) > > end > > end > > ``` > This is appalling. If "best practices" are going to encourage this kind of un-ruby-ish horror, this memoization issue is more urgent to solve than I had expected. Firstly, rbocop is totally optional. Secondly, even rubocop is suggesting something more elegant than the above example: ``` def current_user return @current_user if defined?(@current_user) @current_user = User.find_by(id: session[:user_id]) end ``` Which is, in my humble opinion, pretty common practice for memoizing falsey values in general. > Personally I prefer a DSL like `memo def foo` but this `@||=` idea is pretty interesting in how it communicates this is a syntax that applies to instance variables. Neither DSL nor proposed syntax are good IMO as they add a lot of cognitive burden. Although, I think DSL is still better if anything. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114262 * 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:122951] [Ruby Feature#17316] On memoization
by Dan0042 (Daniel DeLorme) 11 Aug '25

11 Aug '25

Issue #17316 has been updated by Dan0042 (Daniel DeLorme). marksiemers (Mark Siemers) wrote in #note-12: > 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 > ``` This is appalling. If "best practices" are going to encourage this kind of un-ruby-ish horror, this memoization issue is more urgent to solve than I had expected. Personally I prefer a DSL like `memo def foo` but this `@||=` idea is pretty interesting in how it communicates this is a syntax that applies to instance variables. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114255 * 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: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: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