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

[ruby-core:125728] [Ruby Bug#22109] Unexpected or misleading error when subclass of a ractor calls a new method on itself
by miles-georgi (Miles Georgi) 13 Jun '26

13 Jun '26

Issue #22109 has been reported by miles-georgi (Miles Georgi). ---------------------------------------- Bug #22109: Unexpected or misleading error when subclass of a ractor calls a new method on itself https://bugs.ruby-lang.org/issues/22109 * Author: miles-georgi (Miles Georgi) * Status: Open * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hey hey! When I run the following code: ```ruby class SubRactor < Ractor attr_accessor :foo end SubRactor.new { puts foo }.join ``` I get the following error: ``` can not access instance variables of shareable objects from non-main Ractors (Ractor::IsolationError) ``` Unclear if I shouldn't get an error of any sort in this situation, but if this is a legitimate error situation, this error seems inaccurate since Ractors can obviously access instance variables of shareable objects. A tiny script that shows that: ```ruby class C attr_accessor :foo def initialize = self.foo = 100 INSTANCE = new.freeze end raise "not shareable!" unless Ractor.shareable?(C::INSTANCE) Ractor.new { puts C::INSTANCE.foo }.join ``` This prints out 100 as expected instead of giving that error. This happens on both: ruby 4.1.0dev (2026-06-11T14:25:18Z master 8e8682fc23) +PRISM [x86_64-linux] and ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] The script is so puny seems I shouldn't upload the file but let me know if I should just always upload a script file when filing these even when they are trivially small. Cheers! -- https://bugs.ruby-lang.org/

3 5

[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: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) 13 Jun '26

13 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:125718] [Ruby Feature#12639] Speed up require in RubyGems by 5x
by hsbt (Hiroshi SHIBATA) 12 Jun '26

12 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) 12 Jun '26

12 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) 12 Jun '26

12 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) 12 Jun '26

12 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

[ruby-core:125157] [Ruby Feature#21973] Smile argument
by kinoppyd (Yasuhiro Kinoshita) 11 Jun '26

11 Jun '26

Issue #21973 has been reported by kinoppyd (Yasuhiro Kinoshita). ---------------------------------------- Feature #21973: Smile argument https://bugs.ruby-lang.org/issues/21973 * Author: kinoppyd (Yasuhiro Kinoshita) * Status: Open ---------------------------------------- Ruby makes us smile. So I want Ruby to smile too, and that is why I would like to propose this feature. The smile argument makes Ruby smile by allowing a method call to end its argument list with `:)`. smile_method(arg, :) This syntax implicitly supplies keyword arguments by matching the names of local variables in the current scope with the names of the method’s keyword parameters. For example, if a method has the following signature: ```ruby some_method(arg, smile:, hugging:) ``` then these two calls would be equivalent: ```ruby arg = "hello" smile = "smile" hugging = "hugging" some_method(arg, smile:, hugging:) ``` ```ruby arg = "hello" smile = "smile" hugging = "hugging" some_method(arg, :) ``` The motivation behind this feature is the assumption that names used in a method signature are often also used at the call site. For instance, if a library method defines keyword arguments like `(from:, to:)`, I expect that code using that method would often have local variables named `from` and `to` holding the actual values before passing them along. In real application development, when developers adopt a new library, they will usually look at the argument list of the method they want to call. If they intend to use that method as designed, it seems natural that they may also choose the same variable names as those in the method signature. This idea was inspired by Scala’s implicit parameters. It is not exactly the same feature, but as a lazy person, I find the idea of context-driven currying quite appealing. In any case, the real purpose is to make Ruby smile. Happy Ruby! And happy April Fools' Day! -- https://bugs.ruby-lang.org/

4 3