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

[ruby-core:123731] [Ruby Bug#21674] Possible regression in return case in statement
by jandudulski (Jan Dudulski) 07 Jun '26

07 Jun '26

Issue #21674 has been reported by jandudulski (Jan Dudulski). ---------------------------------------- Bug #21674: Possible regression in return case in statement https://bugs.ruby-lang.org/issues/21674 * Author: jandudulski (Jan Dudulski) * Status: Open * ruby -v: 3.4.6 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Suddenly my code started failing in Ruby 3.4.6 and 3.4.7. Shortest code example: ``` ruby args = [:increased] context = Data.define(:event).new(:decreased) case args in [event] context.event in ^event end ``` In Ruby prior to 3.4.6 in returns `false` (as expected) but in 3.4.6 and 3.4.7 it returns `:decreased`. `context.event in ^event` still returns `false`. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:124474] [Ruby Bug#21831] Prism doesn't count underscores in the fraction part of rational float
by nobu (Nobuyoshi Nakada) 07 Jun '26

07 Jun '26

Issue #21831 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21831: Prism doesn't count underscores in the fraction part of rational float https://bugs.ruby-lang.org/issues/21831 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Good. ```console $ ruby3.3 -e 'p 0.1_2r.to_f' 0.12 $ ruby3.4 --parser=parse.y -e 'p 0.1_2r.to_f' 0.12 ``` Wrong. ```console $ ruby3.4 -e 'p 0.1_2r.to_f' 0.012 ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125631] Invitation to RubyConf Community Day
by Ufuk Kayserilioglu 05 Jun '26

05 Jun '26

I am sending the message below on behalf of Rachael Wright-Munn <chaelcodes(a)gmail.com>, who is organizing the RubyConf 2026 Hack Spaces, and is CC'ed to this email. Please direct all future correspondence about the event to her. Thank you! --- Hello ruby-core! We’re reaching out to invite you to participate in Hack Spaces during RubyConf 2026, which is in Las Vegas, NV, from July 14th to 16th. Hack Spaces will take place on Day 2 of the conference (July 15th), during Community Day. Hack Spaces at RubyConf 2026 is a collaborative event dedicated to contributing to open source projects that power the Ruby ecosystem. It's an opportunity for maintainers to collaborate in person and onboard new contributors. You can learn more about this aspect of Community Day here. ( https://storage.ghost.io/c/17/0a/170a5cb5-5524-4ba0-93b6-f17fc9bacca6/conte… ) This year, we'd like to dedicate a space to working on the Ruby programming language. By creating space for cross-project, in-person collaboration between maintainers, we hope to support the open-source community and drive the next innovation in Ruby. We sincerely hope that you attend and find it valuable. We have a site dedicated to sharing information about the projects and their maintainers. We would love to feature any maintainers or contributors who are planning to attend. If you are interested in being featured on the site, please reply to this message with name, photo/avatar, job title, company name, and any socials. As a reminder, all Ruby Core members receive free tickets to RubyConf, please reach out to rubyconf(a)rubycentral.org for assistance in that regard. With appreciation, RubyConf 2026 Program Committee & Staff

1 0

[ruby-core:125083] [Ruby Misc#21960] Improve #backtrace to not confuse terminals
by svoop (Sven Schwyn) 05 Jun '26

05 Jun '26

Issue #21960 has been reported by svoop (Sven Schwyn). ---------------------------------------- Misc #21960: Improve #backtrace to not confuse terminals https://bugs.ruby-lang.org/issues/21960 * Author: svoop (Sven Schwyn) * Status: Open ---------------------------------------- The `#backtrace` of exceptions are currently printed like so: ``` /path/to/whatever.rb:8:in `/' /path/to/whatever.rb:8:in `show' (...) ``` Most terminals recognize `/path/to/whatever.rb:8` as a local file and make it clickable as "open in editor", however, some (e.g. Ghostty) include everything up to the next whitespace, in this case `/path/to/whatever.rb:8:in`. This is then used as an argument to `open` (on macOS) which will not work due to the `:in` part. There are two ways to improve this: ## Replace the colon with a space Given the existence of `#backtrace_locations` which is better suited for programmatically working with backtrace locations, it should not break things to slightly modify the `#backtrace` to look like this: ``` /path/to/whatever.rb:8 in `/' /path/to/whatever.rb:8 in `show' (...) ^^^ space instead of colon ``` ## Add OCS 8 sequences [OCS 8](https://github.com/Alhadis/OSC8-Adoption) are the `<a>` tag for terminal output. While many terminals support it, it might cause visual noise in logs and therefore would have to be an opt-in feature e.g. via a Ruby interpreter argument. -- https://bugs.ruby-lang.org/

8 17

[ruby-core:125620] [Ruby Feature#17944] Remove Socket.gethostbyaddr and Socket.gethostbyname
by Earlopain (Earlopain _) 04 Jun '26

04 Jun '26

Issue #17944 has been updated by Earlopain (Earlopain _). ruby/spec has the following test: ```rb addr = IPAddr.new('::1').hton it 'raises SocketError when the address is not supported by the family' do -> { suppress_warning { Socket.gethostbyaddr(addr, :INET) } }.should.raise(SocketError) end ``` But it doesn't raise and instead returns the following result for me: `["pi.hole", [], 2, "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01"]`. Given https://github.com/ruby/ruby/commit/41977ef59585d1ee42ffcb546aa80f071512b257, it doesn't look I am the only one this happened to. They print warnings for ~6 years now, so it seems wasted time to investigate this. Can we simply remove them now? ---------------------------------------- Feature #17944: Remove Socket.gethostbyaddr and Socket.gethostbyname https://bugs.ruby-lang.org/issues/17944#change-117472 * Author: pvalena (Pavel Valena) * Status: Open ---------------------------------------- It is marked as unsafe by our static analysis. Can it be removed now? It was deprecated in: https://bugs.ruby-lang.org/projects/ruby-master/repository/trunk/revisions/… https://bugs.ruby-lang.org/issues/13097 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125610] [Ruby Misc#22091] Missing Regexp documentation on relative (negative) backreferences
by cryptogopher (crypto gopher) 02 Jun '26

02 Jun '26

Issue #22091 has been reported by cryptogopher (crypto gopher). ---------------------------------------- Misc #22091: Missing Regexp documentation on relative (negative) backreferences https://bugs.ruby-lang.org/issues/22091 * Author: cryptogopher (crypto gopher) * Status: Open ---------------------------------------- I found out about them elsewhere: https://idiosyncratic-ruby.com/11-regular-extremism.html#relative-back-refe…. Description below is sourced from blog linked above: Relative Back-References Back-refs can be relatively referenced from the current position via \k<-n>: "Ruby by"[/(R)(u)(by) \k<-1>/] #=> "Ruby by" -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125609] [Ruby Bug#22090] Enabling Ruby::Box breaks Marshal.load.
by joker1007 (Tomohiro Hashidate) 02 Jun '26

02 Jun '26

Issue #22090 has been reported by joker1007 (Tomohiro Hashidate). ---------------------------------------- Bug #22090: Enabling Ruby::Box breaks Marshal.load. https://bugs.ruby-lang.org/issues/22090 * Author: joker1007 (Tomohiro Hashidate) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-31T10:35:05Z master 12c8599ffa) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This is very simple. ``` ruby class Foo end f = Marshal.dump(Foo.new) Marshal.load(f) ``` # No Ruby::Box This code returns `#<Foo:0x00007fdb9c744da0>`. --- # Ruby::Box enabled This code returns "undefined class/module Foo". ``` marshal_main.rb:5:in 'Marshal.load': undefined class/module Foo (ArgumentError) p Marshal.load(f) ^ from marshal_main.rb:5:in '<main>' ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125562] [Ruby Bug#22078] mswin: `gmp.h` not found with `--with-opt-dir` on Ruby 3.3/3.4
by hsbt (Hiroshi SHIBATA) 02 Jun '26

02 Jun '26

Issue #22078 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22078: mswin: `gmp.h` not found with `--with-opt-dir` on Ruby 3.3/3.4 https://bugs.ruby-lang.org/issues/22078 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: DONTNEED ---------------------------------------- On mswin builds, `win32/Makefile.sub` builds `XCFLAGS` without `XINCFLAGS`, so the include path written by `configure.bat --with-opt-dir=...` never reaches `cl.exe` and `#include <gmp.h>` cannot be resolved. `master` and `ruby_4_0` are fixed by https://github.com/ruby/ruby/commit/13c64a8a20, but neither `ruby_3_4` nor `ruby_3_3` has it. How it surfaces differs between the two: - `ruby_3_4`: `win32/setup.mak` auto-enables GMP whenever gmp is present, so the build tries to use it and fails on the missing `gmp.h`. - `ruby_3_3`: `win32/setup.mak` only enables GMP when `--with-gmp` is explicitly passed. Without the flag the build passes but GMP is never used; with the flag, it fails the same way as 3.4. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:125602] [Ruby Bug#22089] Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects
by kddnewton (Kevin Newton) 01 Jun '26

01 Jun '26

Issue #22089 has been updated by kddnewton (Kevin Newton). Status changed from Open to Closed Closed by 9e8ad9ac0489d8390bc11e5b18f4af065d60898c ---------------------------------------- Bug #22089: Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects https://bugs.ruby-lang.org/issues/22089#change-117449 * Author: Anonymous * Status: Closed * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following is accepted by Prism but rejected by parse.y: ``` $ ruby -cve "if a if b then end" ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] Syntax OK $ ruby --parser=parse.y -cve "if a if b then end" ruby 4.0.0 (2025-12-25 revision 553f1675f3) [arm64-darwin25] -e:1: syntax error, unexpected 'if' modifier, expecting 'then' or '\n' or ';' if a if b then end ^~ ruby: compile error (SyntaxError) ``` The same applies to other statement modifiers (`unless`/`while`/`until`) and to `unless`/`elsif` conditions. For example, all of the following are accepted by Prism but rejected by parse.y: ```ruby if a if b then end if a unless b then end if a while b then end if a until b then end unless a until b then end if x then elsif a if b then end ``` I can also reproduce this on Prism's main branch (1.9.0). Prism already treats the same syntax as a syntax error in `while`/`until` conditions, so it looks like `if`/`unless`/`elsif` conditions should reject it as well, matching both parse.y and Prism's own handling of `while`/`until` conditions. I have a draft patch here: https://github.com/ruby/prism/pull/4120 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125600] [Ruby Bug#22089] Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects
by Kai (kai matsudate) 01 Jun '26

01 Jun '26

Issue #22089 has been updated by Kai (kai matsudate). I'm the reporter. It shows as anonymous due to recreating my account, but I'm following this. ---------------------------------------- Bug #22089: Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects https://bugs.ruby-lang.org/issues/22089#change-117442 * Author: Anonymous * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following is accepted by Prism but rejected by parse.y: ``` $ ruby -cve "if a if b then end" ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] Syntax OK $ ruby --parser=parse.y -cve "if a if b then end" ruby 4.0.0 (2025-12-25 revision 553f1675f3) [arm64-darwin25] -e:1: syntax error, unexpected 'if' modifier, expecting 'then' or '\n' or ';' if a if b then end ^~ ruby: compile error (SyntaxError) ``` The same applies to other statement modifiers (`unless`/`while`/`until`) and to `unless`/`elsif` conditions. For example, all of the following are accepted by Prism but rejected by parse.y: ```ruby if a if b then end if a unless b then end if a while b then end if a until b then end unless a until b then end if x then elsif a if b then end ``` I can also reproduce this on Prism's main branch (1.9.0). Prism already treats the same syntax as a syntax error in `while`/`until` conditions, so it looks like `if`/`unless`/`elsif` conditions should reject it as well, matching both parse.y and Prism's own handling of `while`/`until` conditions. I have a draft patch here: https://github.com/ruby/prism/pull/4120 -- https://bugs.ruby-lang.org/

1 0