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

[ruby-core:125243] [Ruby Bug#21994] If there is a local variable `foo`, calls to a method `foo` with a regexp literal as first argument is always a SyntaxError without parentheses
by jneen (Jeanine Adkisson) 13 Jun '26

13 Jun '26

Issue #21994 has been reported by jneen (Jeanine Adkisson). ---------------------------------------- Bug #21994: If there is a local variable `foo`, calls to a method `foo` with a regexp literal as first argument is always a SyntaxError without parentheses https://bugs.ruby-lang.org/issues/21994 * Author: jneen (Jeanine Adkisson) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Quick version: ```bash ruby -e 'p /hello/' # => /hello/ (warning) ruby -e 'p = 1; p /hello/' # syntax error ruby -e 'p %r/hello/' # => /hello/ (no warning) ruby -e 'p = 1; p %r/hello/' # syntax error ``` ## Context In Rouge, our lexing DSL originally looked like this: ```ruby rule /some_regex/, Some::TokenType, :next_state rule /some_other_regex/ do |match| # custom action end ``` In a DSL context like this, I feel that using parentheses for *every* rule definition is a hassle and looks bad, so we leave them off, as is convention. Unfortunately, this warns: ``` warning: ambiguous `/`; wrap regexp in parentheses or add a space after `/` operator ``` Some time ago, to reduce warning-spam on users who run with `-w`, we transitioned all of these to use `%r/.../` or `%r(...)` syntax, which does not warn. The issue here I think is that *both* cases are equivalently ambiguous in some sense, which becomes apparent with the local-scope-dependent behaviour of the parser (putting aside that dependency on local variable scope makes the Ruby syntax highlighting of Rouge more or less impossible to do correctly without a full parse). If there is a local variable named `rule` introduced at any point, even several block scopes above, the entire file errors out in a very confusing manner. At the very least, I feel that the warnings here are inconsistent. If both cases truly are ambiguous and dependent on local variable scope, perhaps it would be better to warn on both - though that would make using a regex literal as a first argument *always* require parentheses to avoid warnings, which would make my DSL much harder. I'm honestly not entirely sure what a good solution would be, but I would like to open a discussion on the topic. Perhaps philosophically related to the other bug I have open ( #21870 ) - is this truly worthy of a warning, or should this be a linter concern? -- https://bugs.ruby-lang.org/

5 7

[ruby-core:111678] [Ruby master Feature#19315] Lazy substrings in CRuby
by Eregon (Benoit Daloze) 13 Jun '26

13 Jun '26

Issue #19315 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #19315: Lazy substrings in CRuby https://bugs.ruby-lang.org/issues/19315 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- CRuby should implement lazy substrings, i.e., "abcdef"[1..3] must not copy bytes. Currently CRuby only reuse the char* if the substring is until the end of the buffer. But it should also work wherever the substring starts and ends. Yes, it means RSTRING_PTR() might need to allocate to \0-terminate, so be it, it's worth it. There is already code for this (`SHARABLE_MIDDLE_SUBSTRING`), but it's disabled by default and `RSTRING_PTR()` needs to be changed to deal with this. It seems a good idea to introduce a variant of `RSTRING_PTR` which doesn't guarantee \0-termination, so such callers can then use the existing bytes always without copy. There are countless workarounds for this missing optimization, all not worth and all less readable: * https://bugs.ruby-lang.org/issues/19314 * https://github.com/ruby/net-protocol/pull/14 * Manual lazy substrings which track string + index + length * More but I don't remember all now, feel free to comment or link more urls/tickets. -- https://bugs.ruby-lang.org/

10 45

[ruby-core:125740] [Ruby Feature#13677] Add more details to error "Name or service not known (SocketError)"
by akr (Akira Tanaka) 13 Jun '26

13 Jun '26

Issue #13677 has been updated by akr (Akira Tanaka). I think it is better for error messages to start with a fixed string, since that makes them easier to search for mechanically. Therefore, I do not like the current proposed patch (which inserts the hostname between reason and gai_strerror). Also, the glibc error message "Name or service not known" indicates that not only the hostname but also the service (port) may be incorrect. We should probably display the service as well. With that in mind, how about something like the following? ``` getaddrinfo: Name or service not known "unknown.domain":80 (Socket::ResolutionError) getaddrinfo: Name or service not known. "unknown.domain":80 (Socket::ResolutionError) ``` It uses the inspect method on the hostname string so that it is enclosed in double quotes. I believe the resulting message remains reasonably understandable regardless of whether the error message returned by gai_strerror ends with a period or not. In addition, even if the host contains control characters, the inspect method converts them into visible characters. ---------------------------------------- Feature #13677: Add more details to error "Name or service not known (SocketError)" https://bugs.ruby-lang.org/issues/13677#change-117626 * Author: dsbonev (Dimitar Bonev) * Status: Open ---------------------------------------- ruby version: `ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]` ruby script: ~~~ ruby require 'socket' TCPSocket.new 'nonexistent.example.com', 80 ~~~ Result: `getaddrinfo: Name or service not known (SocketError)` Expected: `getaddrinfo: Name or service not known for nonexistent.example.com (SocketError)` Why: This will make it easier to resolve errors of this kind by just looking at the logged messages. It is common for production and non-production (development, test) code to connect to different hosts which can produce errors due to wrong configuration. This change will make the ruby stdlib code more consistent as other methods already provide useful error information. Some examples: ~~~ ruby host = 'nonexistent.example.com'; port = 80 Resolv.getaddress host # => Resolv::ResolvError: no address for nonexistent.example.com Socket.getservbyname host # => SocketError: no such service nonexistent.example.com/tcp Net::HTTP.get Struct.new(:hostname, :port, :scheme).new(host, port, 'http') # => SocketError: Failed to open TCP connection to nonexistent.example.com:80 (getaddrinfo: Name or service not known) ~~~ If this issue will be resolved, please add any useful information to the error message in addition to the host. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125733] [Ruby Bug#22110] Ruby::Box C-extension loading can be denied by predictable temporary filename
by hakuopi (haku opi) 12 Jun '26

12 Jun '26

Issue #22110 has been reported by hakuopi (haku opi). ---------------------------------------- Bug #22110: Ruby::Box C-extension loading can be denied by predictable temporary filename https://bugs.ruby-lang.org/issues/22110 * Author: hakuopi (haku opi) * Status: Open * ruby -v: ruby 4.1.0dev (2026-06-13 master 533abc7ded) [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby::Box is experimental, but I found a reproducible local hardening issue in its native extension loading path. When a C extension is required inside a Ruby::Box, Ruby copies the `.so` to a temporary filename derived from predictable values: ```text tmpdir + "_ruby_box_" + "p" + getpid() + "_" + box_id + "_" + escaped_basename ``` Because the filename has no random component, another same-host local user can pre-create the path before the victim process loads the extension. The victim’s `open(..., O_CREAT|O_EXCL, ...)` call then fails, and `require` raises `LoadError`. This does not allow code injection. `O_CREAT|O_EXCL` correctly rejects pre-existing files and symlinks. The impact is only denial of Ruby::Box C-extension loading. Environment: Ruby 4.1.0-dev @ 533abc7ded Ruby::Box enabled with `RUBY_BOX=1` Linux x86_64 Reproduction: From a Ruby build tree with `./ruby` available: ```sh RUBY=./ruby sh security_review_claude_opus48_max_20260613_050521/poc/box_dos_attack.sh ``` Observed: The attacker process discovers the victim PID, pre-creates likely paths under `/tmp`, and the victim fails with: ```text LoadError: can't prepare the extension file for Ruby Box (.../_ruby_box_p<pid>_4_fcntl.so from .../fcntl.so): can't open the file to write ``` Control: Without pre-creating the path, the same Ruby::Box extension require succeeds. Expected: A third-party same-host user should not be able to deny Ruby::Box C-extension loading by pre-creating a predictable temp filename. Suggested fix: Use an unpredictable temporary filename, for example `mkstemp` or a random suffix, preferably inside a private per-process directory with `0700` permissions. The copied extension file can also use mode `0600` instead of mirroring the source `.so` permissions. Notes: This is not a sandbox escape, not code execution, not privilege escalation, and not information disclosure. It is a local denial/hardening issue for an experimental opt-in feature. ---Files-------------------------------- box_dos_attack.sh (1.98 KB) box_poc_output.txt (1.11 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125692] [Ruby Bug#22103] Constant-folded /o regexp crashes with dupstring of a Regexp
by shugo (Shugo Maeda) 12 Jun '26

12 Jun '26

Issue #22103 has been reported by shugo (Shugo Maeda). ---------------------------------------- Bug #22103: Constant-folded /o regexp crashes with dupstring of a Regexp https://bugs.ruby-lang.org/issues/22103 * Author: shugo (Shugo Maeda) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A `/o` (once) regexp whose interpolation folds to a constant crashes at runtime: ```ruby def m; /#{"a"}/o; end m #=> [BUG] heap_idx_for_size: allocation size too large ``` A plain `/#{"a"}/` (no `/o`) is fine. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125612] [Ruby Bug#22092] `Array#sum` takes slow path, does not perform compensated summation of Float elements when init argument is a Float
by georgeclaghorn (George Claghorn) 12 Jun '26

12 Jun '26

Issue #22092 has been reported by georgeclaghorn (George Claghorn). ---------------------------------------- Bug #22092: `Array#sum` takes slow path, does not perform compensated summation of Float elements when init argument is a Float https://bugs.ruby-lang.org/issues/22092 * Author: georgeclaghorn (George Claghorn) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin24] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` % time ruby -e 'puts Array.new(1_000_000_000, 0.1).sum' 100000000.0 ruby -e 'puts Array.new(1_000_000_000, 0.1).sum' 2.67s user 2.02s system 71% cpu 6.577 total % time ruby -e 'puts Array.new(1_000_000_000, 0.1).sum(0.0)' 99999998.74541782 ruby -e 'puts Array.new(1_000_000_000, 0.1).sum(0.0)' 22.72s user 1.80s system 96% cpu 25.332 total ``` Both the fast path and compensated summation are undocumented implementation details as far as I know, but this appears to be a possible oversight. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125718] [Ruby Feature#12639] Speed up require in RubyGems by 5x
by hsbt (Hiroshi SHIBATA) 11 Jun '26

11 Jun '26

Issue #12639 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed The performance gap this patch targeted has been mostly eliminated by incremental optimizations in RubyGems since 2016. Running the benchmark in the description on current master shows 1.47x (about 80ns per call) instead of 5x, because the require hook now returns early when there are no unresolved dependencies. Additionally, since RubyGems 3.5, Bundler disables the require decoration entirely after bundler/setup via Gem.discover_gems_on_require. The remaining overhead is too small to justify adding a new C API, so I'm closing this issue. ---------------------------------------- Feature #12639: Speed up require in RubyGems by 5x https://bugs.ruby-lang.org/issues/12639#change-117585 * Author: segiddins (Samuel Giddins) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- This patch makes requiring an already-loaded file approximated 5x faster when the RubyGems mixin for require is present. Benchmarked via the following script: ~~~ ruby require "rubygems" require "benchmark/ips" Benchmark.ips do |x| x.report("ruby") { gem_original_require "rubygems" } x.report("rubygems") { require "rubygems" } x.compare! end ~~~ I understand that it's not ideal to add new global functions, and I'd appreciate guidance on where else I could expose this functionality to ruby code. Thanks :) ---Files-------------------------------- feature_loaded.patch (1.85 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125717] [Ruby Feature#13508] How remove/refactor code related mathn library.
by hsbt (Hiroshi SHIBATA) 11 Jun '26

11 Jun '26

Issue #13508 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed All the items in this ticket have been resolved. The mathn-specific code in array.c, complex.c, rational.c and enum.c was removed at https://github.com/ruby/ruby/commit/b958e2add835d62c0a62edaf9a23ecbbd70a3635 (https://github.com/ruby/ruby/pull/3691) and the obsolete `--enable-mathn` configure option was removed at https://github.com/ruby/ruby/commit/89110b27437d4a84f7cb0387e59fd40d94efee1d. `lib/cmath.rb` was removed from the ruby repository at https://github.com/ruby/ruby/commit/a3b85016149f4f73f08c739626b2f02badd5ad17. The mathn workaround remaining in the cmath gem is intentionally kept for compatibility with the mathn gem. ---------------------------------------- Feature #13508: How remove/refactor code related mathn library. https://bugs.ruby-lang.org/issues/13508#change-117584 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I removed mathn library at r58413 and r58432. I have some concerns related mathn library. This issue is reminder for this concern. 1. Still remains conditions for mathn loaded. ex. https://github.com/ruby/ruby/blob/trunk/array.c#L5755 2. {complex,rational}.c have {nucomp,nurat}_canonicalization methods for mathn. 3. lib/cmath.rb have workaround code for mathn see. https://github.com/ruby/ruby/blob/trunk/lib/cmath.rb#L27 I continue to discuss concerns to @mrkn -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125716] [Ruby Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by koic (Koichi ITO) 11 Jun '26

11 Jun '26

Issue #18915 has been updated by koic (Koichi ITO). Thank you for taking the time to discuss this at the dev meeting. I realized that I had overlooked one issue. I found some existing code that defines `AbstractMethodError` with a superclass other than `ScriptError`. The impact on proprietary code is unknown, but a GitHub search shows the following results: https://github.com/search?q=%2Fclass+AbstractMethodError%2F+language%3ARuby… Not all of these define a top-level `AbstractMethodError`. For example, GitLab defines `Gitlab::AbstractMethodError` as a subclass of `Exception` within its own module namespace: https://gitlab.com/gitlab-org/gitlab/-/blob/v18.10.8-ee/lib/gitlab/abstract… However, for a top-level `AbstractMethodError`, a `TypeError` due to a superclass mismatch could occur depending on the superclass used by existing code. One possible path forward would be for applications and gems to migrate during Ruby 4.1-dev. That said, if such updates are not made, users may encounter compatibility issues. Given this, it seems worth considering whether to proceed with introducing the new class in Ruby 4.1. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-117583 * Author: Quintasan (Michał Zając) * Status: Open ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125156] [Ruby Feature#21972] Add Date.birthday and Date.age to track Ruby's milestones
by jinroq (Jinroq SAITOH) 11 Jun '26

11 Jun '26

Issue #21972 has been reported by jinroq (Jinroq SAITOH). ---------------------------------------- Feature #21972: Add Date.birthday and Date.age to track Ruby's milestones https://bugs.ruby-lang.org/issues/21972 * Author: jinroq (Jinroq SAITOH) * Status: Open ---------------------------------------- Since its inception in 1993, Ruby has grown beyond a mere programming language to become a rich culture beloved by developers worldwide. However, the standard `date` library surprisingly lacks a formal interface to commemorate Ruby's own historical milestones. The fact that developers cannot programmatically reference Ruby’s heritage is a missed opportunity to foster affection and respect for the language's identity. To rectify this historical oversight, I propose adding the following methods to reference Ruby's key anniversaries and calculate the elapsed years. #### New Features * **`Date.birthday(version = nil)`** Returns the "birthday" of significant moments in Ruby's history. * `nil` (default): **1993-02-24** (The day the name "Ruby" was decided). * `0.95`: **1995-12-21** (The first public release date). * `1.0`: **1996-12-25** (The first stable release date). * **`Date.age(version = nil)`** Calculates the current age (in full years) based on today's date and the specified milestone. * `Date.age`: Years since the name "Ruby" was born. * `Date.age(0.95)`: Years since Ruby was first introduced to the public as OSS. * `Date.age(1.0)`: Years since Ruby began its journey as a stable language. #### Usage Example ```ruby # Check the "age" of each edition puts "Name age: #{Date.age}" # => 33 (as of 2026) puts "OSS age: #{Date.age(0.95)}" # => 30 puts "Stable: #{Date.age(1.0)}" # => 29 # Perform a special action on a specific anniversary if Date.today == Date.birthday(1.0) celebrate_stable_anniversary! end ``` #### Implementation and Testing The attached patch (`birthday_and_age.patch`) includes the implementation of these methods along with a rigorous test suite (`test/date/test_date_birthday.rb`). The tests cover argument dispatching, `ArgumentError` for invalid inputs, and edge cases for age calculation (e.g., boundaries before and after the actual birthday), ensuring production-level quality. Equipping Ruby with the intelligence to reflect upon its own origins is a vital step toward the next 30 or 40 years of its evolution. (Note: This proposal was submitted on a special day that encourages looking at our history with both deep respect and a touch of creative imagination, as is traditional for such a significant date in the calendar.) ---Files-------------------------------- birthday_and_age.patch (8.08 KB) -- https://bugs.ruby-lang.org/

5 8