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

[ruby-core:124594] [Ruby Bug#21844] Inconsistent ArgumentError message for Data::define.new
by jnchito (Junichi Ito) 18 May '26

18 May '26

Issue #21844 has been reported by jnchito (Junichi Ito). ---------------------------------------- Bug #21844: Inconsistent ArgumentError message for Data::define.new https://bugs.ruby-lang.org/issues/21844 * Author: jnchito (Junichi Ito) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The code below shows `Data::define.new` treats symbol and string keys equivalently: ``` ruby C = Data.define(:a, :b) C.new(a: 1, b: 1) #=> #<data C a=1, b=1> C.new('a' => 1, 'b' => 1) #=> #<data C a=1, b=1> ``` But it acts differently when detecting missing keywords: ```ruby C.new(a: 1) #=> 'Data#initialize': missing keyword: :b (ArgumentError) C.new('a' => 1) #=> 'Data#initialize': missing keywords: :a, :b (ArgumentError) ``` I feel it should work like this: ```ruby C.new('a' => 1) #=> 'Data#initialize': missing keyword: :b (ArgumentError) ``` I created a PR to fix it: https://github.com/ruby/ruby/pull/15910 -- https://bugs.ruby-lang.org/

6 13

[ruby-core:124286] [Ruby Bug#21789] `IO#flush` doesn't invoke fiber scheduler io_write hook
by noteflakes (Sharon Rosner) 15 May '26

15 May '26

Issue #21789 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Bug #21789: `IO#flush` doesn't invoke fiber scheduler io_write hook https://bugs.ruby-lang.org/issues/21789 * Author: noteflakes (Sharon Rosner) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When calling `IO#flush` or closing an IO with unflushed writes, the flushing is done by calling `rb_io_blocking_region_wait` and eventually doing a `write` system call. When done in a non-blocking fiber with an active fiber scheduler, this will invoke the `#blocking_operation_wait` fiber scheduler hook, which will run the system call in a worker thread, and therefore the flushing bypasses the async I/O capabilities of the fiber scheduler. The proposed fix is to test for the presence of a fiber scheduler in `io_flush_buffer_async` and invoke the `#io_write` fiber scheduler hook with the unflushed part of the IO's write buffer. Associated PR here: https://github.com/ruby/ruby/pull/15609 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111146] [Ruby master Bug#19172] `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change?
by ivoanjo (Ivo Anjo) 15 May '26

15 May '26

Issue #19172 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #19172: `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change? https://bugs.ruby-lang.org/issues/19172 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal * ruby -v: (All Ruby versions) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Howdy 👋! I work for Datadog [on the ddtrace gem](https://github.com/DataDog/dd-trace-rb) and I found a... sharp edge on the internal `ruby_thread_has_gvl_p` API. I am aware that `ruby_thread_has_gvl_p` is documented an experimental API that is exported as a symbol but not present on the VM include files. ### Background In the ddtrace profiling component, we setup a signal handler and then periodically send SIGPROF signals to try to interrupt the running Ruby thread (e.g. the thread that is holding the global VM lock or equivalent). In the signal handler, we need to perform some API calls which are not safe to do without the GVL. So we need to check if the signal handler got called in the thread that has the GVL. ### The issue ```ruby int ruby_thread_has_gvl_p(void) { rb_thread_t *th = ruby_thread_from_native(); if (th && th->blocking_region_buffer == 0) { return 1; } else { return 0; } } ``` In its current implementation, `ruby_thread_has_gvl_p` only checks if the thread has a `blocking_region_buffer` or not. Unfortunately, this means that when called from a thread that lost the GVL but not due to blocking (e.g. via `rb_thread_schedule()`), it can still claim that a thread is holding the GVL when that is not the case. I ran into this issue in https://github.com/DataDog/dd-trace-rb/pull/2415, and needed to find a workaround. ### Next steps Since this is an internal VM API, I'm not sure you'd want to change the current behavior, so I was thinking of perhaps two options: * Is it worth changing `ruby_thread_has_gvl_p` to be accurate in the case I've listed? * If not, would you accept a PR to document its current limitations, so that others don't run into the same issue I did? -- https://bugs.ruby-lang.org/

3 3

[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) 14 May '26

14 May '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/

4 5

[ruby-core:125339] [Ruby Feature#22012] Data class should respond to #dig
by kolbrich (Kevin Olbrich) 14 May '26

14 May '26

Issue #22012 has been reported by kolbrich (Kevin Olbrich). ---------------------------------------- Feature #22012: Data class should respond to #dig https://bugs.ruby-lang.org/issues/22012 * Author: kolbrich (Kevin Olbrich) * Status: Open ---------------------------------------- `Data`s cousin, `Struct` already responds to `#dig`. `Data` objects can show up in deeply nested objects as well, and the semantics of this should be nearly identical to `Struct#dig` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:125311] [Ruby Bug#22007] Inconsistent type checking on rescue
by zenspider (Ryan Davis) 14 May '26

14 May '26

Issue #22007 has been reported by zenspider (Ryan Davis). ---------------------------------------- Bug #22007: Inconsistent type checking on rescue https://bugs.ruby-lang.org/issues/22007 * Author: zenspider (Ryan Davis) * Status: Open * ruby -v: 4.0.2 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- this works fine (but I don't think it should): ```ruby begin raise "nope" rescue RuntimeError, /why am I allowed?/, "or me?" => e # yay end ``` whereas this version shows a type error, which seems right: ```ruby begin begin raise "nope" rescue /why am I NOT allowed/, "if I was allowed before?" => e p e end rescue TypeError => te p te end ``` I think all the args on rescue should be checked to be `Module` -- https://bugs.ruby-lang.org/

6 10

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

13 May '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/

8 13

[ruby-core:123484] [Ruby Bug#21640] Core Pathname is missing 3 methods / is partially-defined
by Eregon (Benoit Daloze) 13 May '26

13 May '26

Issue #21640 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21640: Core Pathname is missing 3 methods / is partially-defined https://bugs.ruby-lang.org/issues/21640 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-09T08:06:20Z master a29c90c3b0) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ ruby -e 'puts Pathname.instance_methods(false).sort; puts Pathname.singleton_methods.sort' > core_pathname_methods.txt $ ruby -rpathname -e 'puts Pathname.instance_methods(false).sort; puts Pathname.singleton_methods.sort' > require_pathname_methods.txt $ diff core_pathname_methods.txt require_pathname_methods.txt 36a37 > find 72a74 > rmtree 98a101 > mktmpdir ``` So `#find`, `#rmtree` and `.mktmpdir` are missing from core Pathname. And indeed, they give NoMethodError, e.g. ``` $ ruby -ve 'Pathname.new("doesnotexist").rmtree' ruby 3.5.0dev (2025-10-09T08:06:20Z master a29c90c3b0) +PRISM [x86_64-linux] -e:1:in '<main>': undefined method 'rmtree' for an instance of Pathname (NoMethodError) ``` I think this is confusing and unexpected for most users. Either Pathname should be fully defined or not at all, having a partially-defined Pathname seems particularly confusing (a bit like an autoload that failed in the middle or so). AFAIK the only core class which used to have this was Fiber with `alive?` and `transfer`, that certainly caused its share of confusion, and Fiber has since been fixed, now even without `require "fiber"` Fiber has all methods. Furthermore these 3 methods are not documented as needing `require 'pathname'` in their documentation: https://github.com/ruby/ruby/blob/master/lib/pathname.rb The reason these 3 methods are not in core pathname seems to be (from [this comment](https://github.com/ruby/pathname/issues/64#issuecomment-3388907046)) > That's consensus with akr and me. We should avoid loading other libraries by simply calling methods from the embedded core classes. I understand that concern and I share it, but I think the situation of having a partially-defined Pathname in core is quite problematic. I think there are 2 solutions: * Define all Pathname methods in core. The `require` are done lazily inside the methods so AFAIK there is no technical issue blocking that, but it's not ideal design-wise that a core class can load default gems (i.e. give up that concern for this particular case). * Do not define Pathname in core and let it be a default gem as it was in Ruby 3.4. I discuss the second in more details, because I found more problems than I would have imagined with core Pathname: ## Should Pathname be in core? #17473 proposed to make Pathname core. That sounded great to me at first thought, but as I realize the practical problems with it I'm thinking it's actually better to keep Pathname non-core and as a default gems. Here are concerns with having Pathname in core: 1. Pathname inherently depends on other default gems/stdlib like `find`, `fileutils` and `tmpdir`. This is important to make Pathname useful. The docs even phrase it like this: `ri Pathname` > ... > All functionality from File, FileTest, and some from Dir and > FileUtils is included, in an unsurprising way. It is essentially a > facade for all of these, and more. 2. core Pathname is missing 3 methods compared to gem Pathname (shown above) 3. the pathname gem is likely to gain extra features, methods and bug fixes. For example I see [4 PRs](https://github.com/ruby/pathname/pulls) adding new methods. It means core Pathname will always be outdated and potentially missing some new methods. 4. One can still use the pathname gem even if it's in core, but surprisingly just `require 'pathname'` is not enough: ``` $ gem install pathname Building native extensions. This could take a while... Successfully installed pathname-0.4.0 1 gem installed $ ruby -e 'require "pathname"; puts $".grep(/pathname/)' pathname.so /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/pathname.rb ^ wrong that's the stdlib pathname $ ruby -e 'gem "pathname"; require "pathname"; puts $".grep(/pathname/)' # some warnings, reported in https://github.com/ruby/pathname/issues/66 pathname.so /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+4/gems/pathname-0.4.0/lib/pathname.rb ^ correct ``` This is another source of confusion caused by core pathname. It even happens with Bundler! ``` $ cat Gemfile source "https://rubygems.org" gem "pathname" $ bundle install $ ruby -e 'require "bundler/setup"; require "pathname"; puts $".grep(/pathname/); puts; puts $:' pathname.so /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/pathname.rb /home/eregon/tmp/bundler-pathname/vendor/bundle/ruby/3.5.0+4/gems/pathname-0.4.0/lib /home/eregon/tmp/bundler-pathname/vendor/bundle/ruby/3.5.0+4/extensions/x86_64-linux/3.5.0+4-static/pathname-0.4.0 /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+4/gems/bundler-2.8.0.dev/lib /home/eregon/prefix/ruby-master/lib/ruby/site_ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/site_ruby/3.5.0+4/x86_64-linux /home/eregon/prefix/ruby-master/lib/ruby/site_ruby /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby/3.5.0+4/x86_64-linux /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/x86_64-linux $ bundle exec ruby -e 'require "pathname"; puts $".grep(/pathname/); puts; puts $:' same as above ``` I'm not sure why, but that seems a serious bug that the `pathname` gem apparently can't be used at all with Bundler. 4. due to this difference in terms of methods for core & gem pathname it seems complicated to keep core Pathname and gem Pathname in sync, since e.g. everything is naturally in one `.rb` file in the gem, but in two `.rb` files in core 5. the pathname gem has to `remove_const :Pathname` to avoid conflicts and warnings in https://github.com/ruby/pathname/blob/4689b0b78d081ae855f325e086d95803fa5bd…. This is bad for Ruby JITs, especially if core Pathname methods might have been used, as it will invalidate JITs compilations, invalidate some inline caches (also bad for the interpreter), caused the JIT to do more compilations which means slower warmup, makes it much harder to persist JITed code across process executions, etc. Based on all of these I think it would actually be better to not have Pathname in core, and let it be a default gem. Having to `require "pathname"` as one always needed to do so far seems far better than a partially-defined core Pathname with rough edge cases (those concerns). -- https://bugs.ruby-lang.org/

7 24

[ruby-core:117434] [Ruby master Bug#20409] Missing reporting some invalid breaks
by kddnewton (Kevin Newton) 13 May '26

13 May '26

Issue #20409 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20409: Missing reporting some invalid breaks https://bugs.ruby-lang.org/issues/20409 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- -- https://bugs.ruby-lang.org/

4 12

[ruby-core:125184] [Ruby Feature#21981] Remove CREF rewriting for methods on cloned classes/modules
by jhawthorn (John Hawthorn) 13 May '26

13 May '26

Issue #21981 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #21981: Remove CREF rewriting for methods on cloned classes/modules https://bugs.ruby-lang.org/issues/21981 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- When a class or module is cloned, Ruby currently rewrites the CREF (constant reference) chain of each copied method so that it points at the new class instead of the original. I don't think this should happen, and methods on a cloned class should retain their original lexical scope. This behaviour was introduced in Ruby 1.9 to fix [Bug #7107], which was reporting that a constant in the original class wasn't available. I think it was done this way because of Ruby's implementation at that time rather than a design choice. This had further changes and fixes in [Bug #10885], [Bug #15877] which were crashes or inconsistencies (stale cache). I'd like us to revisit the design of this behaviour so that it's more intuitive and consistent. ``` ruby class C A = 1 def a; A; end end D = C.clone D.const_set(:A, 2) p C.new.a # => 1 p D.new.a # => 2, but I think it should be 1 ``` In most all other cases in Ruby, methods keep their original lexical scope for constant references: inheritance, mixins, `define_method(..., klass.instance_method(...))`, etc. Cloning a class should behave the same. I think cloning a class is fairly rare, and setting constants on the cloned class more so, but this could be a compatibility issue. This affects `@@class_variables` as well as `CONSTANTS`. FWIW, truffleruby doesn't seem to have this behaviour (which makes sense, part of why I want to remove it is that it's awkward for JIT compiling 😅). https://github.com/ruby/ruby/pull/16651 -- https://bugs.ruby-lang.org/

2 1