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

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

12 Feb '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/

4 10

[ruby-core:124312] [Ruby Feature#21796] unpack variant that returns the final offset
by nobu (Nobuyoshi Nakada) 12 Feb '26

12 Feb '26

Issue #21796 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #21796: unpack variant that returns the final offset https://bugs.ruby-lang.org/issues/21796 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- mame (Yusuke Endoh) wrote in #note-4: > It's a shame `unpack` doesn't tell you how many bytes it read. You'd probably want a `unpack` variant that returns the final offset too, or a specifier that returns the current offset (like `o`?). > > ```ruby > bytes = "\x01\x02\x03" > offset = 0 > leb128_value1, offset = bytes.unpack("Ro", offset: offset) #=> 1 > leb128_value2, offset = bytes.unpack("Ro", offset: offset) #=> 2 > leb128_value3, offset = bytes.unpack("Ro", offset: offset) #=> 3 > ``` mame (Yusuke Endoh) wrote in #note-6: > > You could tell how many bytes you read based on the size of the leb128_value returned. > > That apparoach is unreliable because LEB128 is redundant. For example, both `"\x03"` and `"\x83\x00"` are valid LEB128 encodings of the value 3. > See the note of the section Values - Integers, in the Wasm spec. > https://webassembly.github.io/spec/core/binary/values.html#integers -- https://bugs.ruby-lang.org/

4 6

[ruby-core:124258] [Ruby Feature#21785] Add signed and unsigned LEB128 support to pack / unpack
by tenderlovemaking (Aaron Patterson) 12 Feb '26

12 Feb '26

Issue #21785 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21785: Add signed and unsigned LEB128 support to pack / unpack https://bugs.ruby-lang.org/issues/21785 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Hi, I'd like to add signed and unsigned LEB128 support to the pack and unpack methods. LEB128 is a variable length encoding scheme for integers. You can read the wikipedia entry about it here: https://en.wikipedia.org/wiki/LEB128 LEB128 is used in DWARF, WebAssembly, MQTT, and Protobuf. I'm sure there are other formats, but these are the ones I'm familiar with. I sent a pull request here: https://github.com/ruby/ruby/pull/15589 I'm proposing `K` for the unsigned version and `k` for the signed version. I just picked `k` because it was available, I'm open to other format strings. Thanks for consideration! -- https://bugs.ruby-lang.org/

3 10

[ruby-core:124775] [Ruby Feature#19107] Allow trailing comma in method signature
by matz (Yukihiro Matsumoto) 12 Feb '26

12 Feb '26

Issue #19107 has been updated by matz (Yukihiro Matsumoto). I've been persuaded. I'll accept it. It's better not to allow commas to appear after certain points (like after `&block` and `...`). Matz. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116386 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123449] [Ruby Bug#21633] A `rb_thread_call_without_gvl` loop can cause the fiber scheduler to ignore signals.
by ioquatix (Samuel Williams) 12 Feb '26

12 Feb '26

Issue #21633 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21633: A `rb_thread_call_without_gvl` loop can cause the fiber scheduler to ignore signals. https://bugs.ruby-lang.org/issues/21633 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- The gRPC gem calls `rb_thread_call_without_gvl` in a loop, and doesn't exit when interrupts are delivered if `Thread.handle_interrupt(::SignalException => :never)` is used by the scheduler to create a safe point for asynchronous signal handling. While this may not be considered a bug in any particular part of the system, the combination of the behaviour creates a situation where gRPC can hang for a long time and ignores SIGINT / SIGTERM. ## gRPC Failure Analysis From [`src/ruby/ext/grpc/rb_completion_queue.c`](https://github.com/samuel-williams-shopify/grpc/blob/debug/src/ruby/ext/grpc/rb_completion_queue.c): ```c static void unblock_func(void* param) { next_call_stack* const next_call = (next_call_stack*)param; next_call->interrupted = 1; // ← SIGINT causes this flag to be set } grpc_event rb_completion_queue_pluck(grpc_completion_queue* queue, void* tag, gpr_timespec deadline, const char* reason) { // ... do { next_call.interrupted = 0; // ← Reset flag rb_thread_call_without_gvl(grpc_rb_completion_queue_pluck_no_gil, (void*)&next_call, unblock_func, (void*)&next_call); if (next_call.event.type != GRPC_QUEUE_TIMEOUT) break; } while (next_call.interrupted); // ← The problem! If interrupted, LOOP AGAIN! return next_call.event; } ``` The loop explicitly retries after interruption, making SIGINT/SIGTERM ineffective. This might be considered the expected behaviour if `Thread.handle_interrupt` is used. However, the goal of `Thread.handle_interrupt` in the fiber scheduler is to create a safe point for signal handling, not to prevent them completely. Since this loop never yields back to the scheduler, no such chance exists, and the loop will continue indefinitely. As `rb_thread_call_without_gvl` invokes `vm_check_ints_blocking`, one solution is to yield to the scheduler in the case that there are pending interrupts. This gives the scheduler a chance to handle the incoming SIGINT / SIGTERM signals at the safe point. For a full reproduction of the issue using gRPC: https://github.com/samuel-williams-shopify/grpc-interrupt For the proposed fix: https://github.com/ruby/ruby/pull/14700 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:124773] [Ruby Feature#18841] Proposal: autoload_relative
by ioquatix (Samuel Williams) 12 Feb '26

12 Feb '26

Issue #18841 has been updated by ioquatix (Samuel Williams). Status changed from Open to Closed Closing in favour of https://bugs.ruby-lang.org/issues/15330 ---------------------------------------- Feature #18841: Proposal: autoload_relative https://bugs.ruby-lang.org/issues/18841#change-116382 * Author: fxn (Xavier Noria) * Status: Closed ---------------------------------------- In my experience, autoloads often reflect an existing hierarchical structure. If a project does not use Zeitwerk, and the user declares autoloads for a class or module, chances are they are for child constants. As an example, see the [`ActiveRecord` module](https://github.com/rails/rails/blob/main/activerecord/lib/active_re…. (Those ones do not have a second argument because we define wrapper that derives it by convention, [here](https://github.com/rails/rails/blob/main/activesupport/lib/active_sup…) I think it would be convenient to have an `autoload_relative` in the line of `Kernel#require_relative`. It would make existing patterns more concise, and as a practical consequence, you skip `$LOAD_PATH` lookups too. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124553] [Ruby Misc#21839] DevMeeting-2026-02-12
by mame (Yusuke Endoh) 12 Feb '26

12 Feb '26

Issue #21839 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21839: DevMeeting-2026-02-12 https://bugs.ruby-lang.org/issues/21839 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2026/02/12 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2026/02/09. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

10 11

[ruby-core:124771] [Ruby Feature#15330] autoload_relative
by ioquatix (Samuel Williams) 12 Feb '26

12 Feb '26

Issue #15330 has been updated by ioquatix (Samuel Williams). Assignee changed from matz (Yukihiro Matsumoto) to ioquatix (Samuel Williams) https://github.com/ruby/ruby/pull/16148 ---------------------------------------- Feature #15330: autoload_relative https://bugs.ruby-lang.org/issues/15330#change-116380 * Author: marcandre (Marc-Andre Lafortune) * Status: Assigned * Assignee: ioquatix (Samuel Williams) ---------------------------------------- I'd like to propose a way to autoload a constant using a relative path. It could look like: ``` autoload_relative :MyConst, 'models/my_const' ``` My proposal raises two questions: 1) what's the future of `autoload`? I believe that `autoload` has been there for years, it is used successfully and has no real alternative. I looked at a sample of 430 top gems (took the 500 top ranked according to Libraries.io, removed those that I failed to process). The number of those gems that appear to use `autoload` at least once is 94 of those (22%). The number of lines in the code where `autoload` is called can be quite big. The top 5 are: vagrant: 235 yard: 206 ffaker: 155 aws-sdk: 152 rdoc: 92 This is a minimum bound, as some gems might be using loops, my processing would only detect the one place in the code with `autoload`. 2) are many autoladed paths relative? My preliminary numbers indicate that of the 94 gems using autoload, at least 75 are autoloading some relative files. That's a lower bound, as my algorithm is pretty crude and will only count the simplest cases as being relative. An example of gem my algorithm does not detect is `yard`, because the author wrote a small method to map the relative paths to global paths (code here: https://github.com/lsegal/yard/blob/master/lib/yard/autoload.rb#L3 ) Of those where my processing detects the relative requires, a vast majority are relative. The average is that 94% of autoloaded files are relative and would benefit from `require_relative` In summary: I am convinced that `autoload` should remain in Ruby indefinitely. `autoload_relative` would actually be more useful than `autoload`. Even if the future of `autoload` remains uncertain, I would recommend adding `autoload_relative`; if it is ever decided to actually remove `autoload`, removing `autoload_relative` would not really add to the (huge) burden of gem maintainers. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124631] [Ruby Bug#21851] Performance difference between / operator and fdiv
by mbrown1intel (Michael Brown) 11 Feb '26

11 Feb '26

Issue #21851 has been reported by mbrown1intel (Michael Brown). ---------------------------------------- Bug #21851: Performance difference between / operator and fdiv https://bugs.ruby-lang.org/issues/21851 * Author: mbrown1intel (Michael Brown) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Benchmarking fdiv against the / operator, it seems like fdiv is significantly slower. As far as I'm aware there's no functional difference between these two methods. I first ran this on 2.6, and then checked against 4.0 to make sure it hadn't been fixed in the meantime, and saw the same results. ``` ruby require 'benchmark' n = 500_000_000 c = nil Benchmark.bm do |benchmark| benchmark.report("to_f ") do n.times do |i| c = n / i.to_f end end benchmark.report("fdiv ") do n.times do |i| c = n.fdiv(i) end end end ``` ``` user system total real to_f 37.672000 0.110000 37.782000 ( 38.714876) fdiv 113.016000 0.265000 113.281000 (116.428442) ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:124769] [Ruby Bug#21874] `PrettyPrint::SingleLine` is not API-compatible with `PrettyPrint`, breaking `PP` in some cases
by trinistr (Alexander Bulancov) 11 Feb '26

11 Feb '26

Issue #21874 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Bug #21874: `PrettyPrint::SingleLine` is not API-compatible with `PrettyPrint`, breaking `PP` in some cases https://bugs.ruby-lang.org/issues/21874 * Author: trinistr (Alexander Bulancov) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `PP` expects that a `#pretty_print` method can be used with both `PrettyPrint` and `PrettyPrint::SingleLine` interchangeably. This is used to [implement](https://github.com/ruby/pp/blob/b6f81ef83f9137c2300cb5eb96d44041… `#pretty_print_inspect`. As can be seen from `PP#pp`, a `NoMethodError` is expected when an object does not have `#pretty_print`, so it is [replaced](https://github.com/ruby/pp/blob/b6f81ef83f9137c2300cb5eb96d440419… with `Kernel#inspect`. As far as I can tell, `PrettyPrint::SingleLine` is intended to be compatible with regular `PrettyPrint`, considering it has no-op [methods and arguments](https://github.com/ruby/prettyprint/blob/c2ed83ca24f67a7ca6896d3…. However, it is missing some less-used methods: `#fill_breakable`, `#group_sub` and also `#current_group`, `#break_outmost_groups` and `attr_reader`s. I think only the first two are intended to be used by pretty-printed objects themselves, other methods are for use by output buffers a,d thus expected to be mssing. I'm personally interested in using `#fill_breakable`, because `#breakable` creates too many unneeded newlines in my case. Implementing `#pretty_print` for my [class](https://github.com/trinistr/vector_number/blob/6968e3ea534dc21e5bb0f… works well for IRB and `pp`: ```ruby irb(main):001> v = VectorNumber[1, "a", "z"] => (1 + 1⋅"a" + 1⋅"z") irb(main):002> pp v (1 + 1⋅"a" + 1⋅"z") => (1 + 1⋅"a" + 1⋅"z") ``` But `#pretty_print_inspect` inserts stringified instance when encountering `fill_breakable` due to `NoMethodError`: ```ruby irb(main):003> v.pretty_print_inspect => "(1#<VectorNumber:0x00007fcdd5bb10c0 ...>" ``` Implementing `#fill_breakable` and `#group_sub` for `PrettyPrint::SingleLine` is trivial, I can make a PR if needed. -- https://bugs.ruby-lang.org/

1 0