June 2026 - ruby-core - ml.ruby-lang.org

[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

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

01 Jun '26

Issue #22089 has been reported by Impotency6272 (kai matsudate). ---------------------------------------- Bug #22089: Prism accepts statement modifiers in if/unless/elsif conditions that parse.y rejects https://bugs.ruby-lang.org/issues/22089 * Author: Impotency6272 (kai matsudate) * 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