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

[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:122925] [Ruby Feature#21533] Introduce `Time#am?` and `Time#pm?`
by matheusrich (Matheus Richard) 07 Aug '25

07 Aug '25

Issue #21533 has been reported by matheusrich (Matheus Richard). ---------------------------------------- Feature #21533: Introduce `Time#am?` and `Time#pm?` https://bugs.ruby-lang.org/issues/21533 * Author: matheusrich (Matheus Richard) * Status: Open ---------------------------------------- This proposal adds two predicate methods to `Time`: ```ruby Time.utc(2000, 1, 1, 11, 59, 59).am? # => true Time.utc(2000, 1, 1, 12, 0, 0).pm? # => true ``` * `am?` returns true when the hour is less than 12. * `pm?` returns true when the hour is 12 or greater. These methods provide a clear and expressive way to branch logic based on time of day. For example: ```ruby def reminder_deferral_options options = [] options << ["Later today", "later_today"] if Time.now.am? options << ["Tomorrow morning", "tomorrow_morning"] options << ["Pick a date/time…", "custom"] options end ``` This is a common pattern in applications involving reminders and scheduling. The method names are intuitive, and the semantics are well understood. The implementation is in [this Pull Request](https://github.com/ruby/ruby/pull/14133). -- https://bugs.ruby-lang.org/

2 2

[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:120694] [Ruby master Bug#21039] Ractor.make_shareable breaks block semantics (seeing updated captured variables) of existing blocks
by Eregon (Benoit Daloze) 06 Aug '25

06 Aug '25

Issue #21039 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21039: Ractor.make_shareable breaks block semantics (seeing updated captured variables) of existing blocks https://bugs.ruby-lang.org/issues/21039 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: ko1 (Koichi Sasada) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby def make_counter count = 0 nil.instance_exec do [-> { count }, -> { count += 1 }] end end get, increment = make_counter reader = Thread.new { sleep 0.01 loop do p get.call sleep 0.1 end } writer = Thread.new { loop do increment.call sleep 0.1 end } ractor_thread = Thread.new { sleep 1 Ractor.make_shareable(get) } sleep 2 ``` This prints: ``` 1 2 3 4 5 6 7 8 9 10 10 10 10 10 10 10 10 10 10 10 ``` But it should print 1..20, and indeed it does when commenting out the `Ractor.make_shareable(get)`. This shows a given block/Proc instance is concurrently broken by `Ractor.make_shareable`, IOW Ractor is breaking fundamental Ruby semantics of blocks and their captured/outer variables or "environment". It's expected that `Ractor.make_shareable` can `freeze` objects and that may cause some FrozenError, but here it's not a FrozenError, it's wrong values being read. I think what should happen instead is that `Ractor.make_shareable` should create a new Proc and mutate that. However, if the Proc is inside some other object and not just directly the argument, that wouldn't work (like `Ractor.make_shareable([get])`). So I think one fix would to be to only accept Procs for `Ractor.make_shareable(obj, copy: true)`. FWIW that currently doesn't allow Procs, it gives `<internal:ractor>:828:in 'Ractor.make_shareable': allocator undefined for Proc (TypeError)`. I think the only other way, and I think it would be a far better way would be to not support making Procs shareable with `Ractor.make_shareable`. Instead it could be some new method like `isolated { ... }` or `Proc.isolated { ... }` or `Proc.snapshot_outer_variables { ... }` or so, only accepting a literal block (to avoid mutating/breaking an existing block), and that would snapshot outer variables (or require no outer variables like Ractor.new's block, or maybe even do `Ractor.make_shareable(copy: true)` on outer variables) and possibly also set `self` since that's anyway needed. That would make such blocks with different semantics explicit, which would fix the problem of breaking the intention of who wrote that block and whoever read that code, expecting normal Ruby block semantics, which includes seeing updated outer variables. Related: #21033 https://bugs.ruby-lang.org/issues/18243#note-5 Extracted from https://bugs.ruby-lang.org/issues/21033#note-14 -- https://bugs.ruby-lang.org/

5 16

[ruby-core:122797] [Ruby Feature#21515] Add `&return` as sugar for `x=my_calculation; return x if x`
by nhorton (Noah Horton) 06 Aug '25

06 Aug '25

Issue #21515 has been reported by nhorton (Noah Horton). ---------------------------------------- Feature #21515: Add `&return` as sugar for `x=my_calculation; return x if x` https://bugs.ruby-lang.org/issues/21515 * Author: nhorton (Noah Horton) * Status: Open ---------------------------------------- Let me preface this by saying I have no marriage to the exact keyword name of `&return`. # Problem It is very common to have an early return in code where you get some initial value and return it if it is non-null. i.e. ``` return my_calculation(input_a, input_b) if my_calculation(input_a, input_b) ``` That form on its own is verbose and one where you need to look at it for a moment to confirm it is the same code on either side of the if. If `my_calculation` is non-trivial at all, it normally gets turned into something with a variable: ``` my_calc = my_calculation(input_a, input_b) return my_calc if my_calc ``` That is now two lines. The worse scenario, however, is if the user did not bother doing that and my_calculation turned out to be expensive (and they did not know it). # Proposal I propose a syntax of `&return my_calculation(input_a, input_b)` where it will evaluate the argument and return it as the result of the method if it is non-nil, otherwise it will continue on. # Alternatives ## Do Nothing There is no way to work around this with rolling your own methods. You can't make a `returnif` method or something yourself since you can't do a return in the caller's scope. ## Different Name The best other name I saw were permutations of `returnif`. The biggest issue I see is the similarity of the following two statements: ``` return if foo returnif foo ``` Those are obviously very, very different statements, but are somewhat similar. However, things like this are common, and the code is still quite distinct on those, so I think it is acceptable. Ultimately, this feels so similar to the safe navigator that using `&` in this context feels appropriate. Thank you all for your consideration. -- https://bugs.ruby-lang.org/

9 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:122898] [Ruby Feature#21527] Proposal: Math.log1p and Math.expm1
by mame (Yusuke Endoh) 06 Aug '25

06 Aug '25

Issue #21527 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #21527: Proposal: Math.log1p and Math.expm1 https://bugs.ruby-lang.org/issues/21527 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- Let's add `Math.log1p` and `Math.expm1`. * `Math.log1p(x)`: Computes `Math.log(x + 1)` * `Math.expm1(x)`: Computes `Math.exp(x) - 1` These methods are often more accurate than the straightforward computation, especially when `x` is close to zero. ``` # The current approach loses precision p Math.log(1 + 1.0e-16) #=> 0.0 p Math.exp(1.0e-16) - 1 #=> 0.0 # The proposed methods return the accurate result p Math.log1p(1.0e-16) #=> 1.0e-16 p Math.expm1(1.0e-16) #=> 1.0e-16 ``` Note that they are very standard; the C99 even defines `log1p()` and `expm1()`. Other major programming languages (Python, JavaScript, Java, Go, Rust, etc.) also provide them. PR: https://github.com/ruby/ruby/pull/14087 -- https://bugs.ruby-lang.org/

2 3

[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:120873] [Ruby master Bug#21111] RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs
by stanhu (Stan Hu) 05 Aug '25

05 Aug '25

Issue #21111 has been reported by stanhu (Stan Hu). ---------------------------------------- Bug #21111: RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs https://bugs.ruby-lang.org/issues/21111 * Author: stanhu (Stan Hu) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- As reported in https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/2222 and https://trac.macports.org/ticket/70750, we've had numerous macOS users experience problems with compiling Ruby C++ extensions after upgrading to XCode 16. Users have had to fix their XCode setups and reinstall Ruby when this happens. It turns out that when Ruby can't build a CXX program, it essentially sets CXX to the `false` string. From https://github.com/ruby/ruby/blob/7317f96727725ca37ddb06011918deb841de371c/…: ``` AS_IF([test -n "${rb_there_is_in_fact_no_gplusplus_but_autoconf_is_cheating_us}"], [ AC_MSG_NOTICE([Test skipped due to lack of a C++ compiler.]) ], [test -n "${CXX}"], [ RUBY_WERROR_FLAG([ AC_MSG_CHECKING([whether CXXFLAGS is valid]) AC_LANG_PUSH(C++) AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include <cstdio>]], [[]])], [AC_MSG_RESULT(yes)],[ AC_MSG_RESULT(no) # The message mentions CXXFLAGS, but CPPFLAGS might also affects. AC_MSG_WARN([something wrong with CXXFLAGS="$CXXFLAGS"]) CXX=false ``` This causes C++ extensions, such as `unf_ext`, to fail while attempting to compile native extensions. There are no error messages because `false` is executed, so users only see: ``` Installing unf_ext 0.0.8.2 with native extensions Gem::Ext::BuildError: ERROR: Failed to build gem native extension. current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext /Users/kerrizor/.rvm/rubies/ruby-3.3.7/bin/ruby extconf.rb checking for -lstdc++... yes creating Makefile current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext make DESTDIR\= sitearchdir\=./.gem.20250203-69237-u2oi17 sitelibdir\=./.gem.20250203-69237-u2oi17 clean current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext make DESTDIR\= sitearchdir\=./.gem.20250203-69237-u2oi17 sitelibdir\=./.gem.20250203-69237-u2oi17 compiling unf.cc make: *** [unf.o] Error 1 ``` `unf_ext` only checks whether `RbConfig::CONFIG['CXX']` is defined, not that it is `false`: https://github.com/knu/ruby-unf_ext/blob/c72a36d0a5ea9fe3950611b0f289fc68a2…. Questions: 1. Should CXX just be set to `nil`? Or should all C++ extensions be expected to check for `false`? The latter seems surprising to me. 2. Should there be a way to fail the Ruby build if a valid C++ compiler is not found? -- https://bugs.ruby-lang.org/

6 6

[ruby-core:122917] [Ruby Feature#21532] Define most of Pathname in Ruby code
by Eregon (Benoit Daloze) 05 Aug '25

05 Aug '25

Issue #21532 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21532: Define most of Pathname in Ruby code https://bugs.ruby-lang.org/issues/21532 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: Eregon (Benoit Daloze) ---------------------------------------- There was discussion in #17473 and before to define most of Pathname in Ruby code and not in the C extension. I have made a PR to achieve that: https://github.com/ruby/pathname/pull/57 I would like to merge it soon to avoid conflicts. Once upon a time, Pathname was pure-Ruby: https://github.com/ruby/ruby/blob/95bc02237635d3fe42532bfe53038257575cee75/… This PR goes back to that, and reuses that original Ruby code, but keeps the C extension implementation of `<=>` and `sub` as those two are significantly faster. The other Pathname methods are actually faster in Ruby than in C, because all these methods just do `rb_funcall()` and `rb_ivar_get()` and those in C code have no inline cache, but the corresponding method calls and `@path` have inline caches in Ruby code. https://railsatscale.com/2023-08-29-ruby-outperforms-c/ is an explanation of that. Therefore having Pathname defined in Ruby seems a clear win for many reasons: * Much clearer implementation, so easier to read what the code does * Easier to maintain * Safer (no risk of accessing out of bounds memory or e.g. passing the wrong number of arguments to `rb_funcall`) * Actually faster, because of these inline caches, see numbers at the end of https://github.com/ruby/pathname/pull/57#issue-3234862768 * Better for JITs as they can optimize this, notably `...` vs the C extension being a blackbox * Works on JRuby (which does not support C extensions) * Faster on TruffleRuby (where a C extension for this is inefficient as it causes needless Ruby->C->Ruby transitions) -- https://bugs.ruby-lang.org/

1 0