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

[ruby-core:125059] [Ruby Bug#21824] performance regression in regexp matching after update to 4.0
by mackuba (Kuba Suder) 17 Mar '26

17 Mar '26

Issue #21824 has been updated by mackuba (Kuba Suder). @khasinski Looks like this was not backported to the branch from which 4.0.1/4.0.2 were packaged?… :\ ---------------------------------------- Bug #21824: performance regression in regexp matching after update to 4.0 https://bugs.ruby-lang.org/issues/21824#change-116760 * Author: mackuba (Kuba Suder) * Status: Closed * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- TLDR: a change in the regexp algorithm in regcomp.c merged around October was supposed to speed up the matching, but it seems it has slowed it down more in practice. === I'm running a service written in Ruby which serves some number of Bluesky feeds. As part of this service, I have a process that connects to a websocket API (w/ EventMachine), reads from it all new posts made on the network in real time (on the order of ~100 posts per second on average lately), and passes each post through a #post_matches? method in about 20 feed objects, each of which has a number of regexps configured (most have around 20-30, but one has a few hundred, probably something like 900 regexps in total). If a given post's text (up to 300 unicode characters) matches any of the regexps of the given feed (and/or matches some additional conditions), it's added to this feed in the database. I often use a slightly older version of this project with a fixed pre-downloaded chunk of the posts stream, with ~100k random but real posts in one large binary file, as a benchmark on different versions of Ruby. So I ran it again on 4.0 after it was released a week ago, and I got this: https://bsky.app/profile/mackuba.eu/post/3mb2quhdoqs23 The numbers are the calculated speed of processing, in events per second, after going through the whole sample of 100k events and a full set of feeds. So there was a 5-6% slowdown on Ruby 4.0 vs. Ruby 3.4 (with or without YJIT), putting it below any version of Ruby since 3.0. I started profiling which specific parts of the code got slower, and I narrowed it down to regexp matching (the full loop also does e.g. decoding of data from a binary format from the file). I made a demo project reproducing this here (note, linking to a slightly earlier commit): https://tangled.org/mackuba.eu/ruby4.0-regexp-test/tree/63e208de944debdc0a6…. There are 940 posts here in the sample and 17 regexps, and running 1000 loops takes 7 seconds on Ruby 3.4, but 13.5s on 4.0 (so almost 2x longer). Then, I started digging into the details to see if some specific posts or specific regexps cause the slowdown. It turned out that most of the 17 regexps, if tested alone, work about the same on 3.4 & 4.0, but two work around 4x slower: /\bslackware\b/i and /\bkde plasma\b/i. (This seems to be not only about the length of the regexp, but also specific characters, because e.g. /\blongstring\b/i does not trigger this effect.) It also seems that this only happens if the searched string contains non-ASCII characters. An updated, more minimal version of the demo is here: https://tangled.org/mackuba.eu/ruby4.0-regexp-test/tree/d9e145c1e9f39fca6dd…. One regexp and one string. With a million loops, it takes 0.75s on Ruby 3.4, but 2.7s on Ruby 4.0. (No change on latest master, ruby 4.1.0dev (2026-01-05T17:18:47Z master 7e81bf5c0c), i.e. it's still much slower than on 3.4.) If the few non-ASCII characters (apostrophe, ndash, ellipsis, TM) are removed from the string, the slowdown goes away. Finally, with some help from Codex I tried to track down which specific change between 3.4 and 4.0 caused this slowdown. It turned out to be this commit: https://github.com/ruby/ruby/commit/981ee02c7c664f19b983662d618d5e6bd87d1739, authored in November 2017 (!), but merged around 31st October this year. It says it "fixes performance problem with /k/i and /s/i". I'm not familiar with these string search algorithms so I'm not able to evaluate this in detail or say how this could be fixed, but from the description I'm assuming that it improves performance in some cases of text/regexp, but apparently degrades it in some others like mine. Since in my main test of a practical scenario which matches ~100k posts against ~900 regexps, as well as the earlier demo which matches 940 posts against 17 regexps, the updated version in 4.0 is slower (5% and 47% slower, respectively), my guess is that the net result will generally be negative, i.e. that this change committed in October makes more cases slower than it makes faster. But like I said, I don't know enough about regexp algorithms to analyze this deeper, I can only report my results. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124660] [Ruby Feature#21858] `Kernel#Hash` considers `to_h` too
by ccmywish (Aoran Zeng) 17 Mar '26

17 Mar '26

Issue #21858 has been reported by ccmywish (Aoran Zeng). ---------------------------------------- Feature #21858: `Kernel#Hash` considers `to_h` too https://bugs.ruby-lang.org/issues/21858 * Author: ccmywish (Aoran Zeng) * Status: Open ---------------------------------------- 1. `Kernel#Integer` uses `to_int` first and `to_i` second 2. `Kernel#Array` uses `to_ary` first and `to_a` second 3. `Kernel#Hash` only uses `to_hash` I don't quite understand why there is a need for differential treatment here. I admit that maybe the only benefit of considering `to_h` secondly is that it enables multiple APIs to maintain consistency. -- https://bugs.ruby-lang.org/

4 11

[ruby-core:124857] [Ruby Bug#21921] Hash inconsistent ==, >=, <= behavior
by cohen (Cohen Carlisle) 17 Mar '26

17 Mar '26

Issue #21921 has been reported by cohen (Cohen Carlisle). ---------------------------------------- Bug #21921: Hash inconsistent ==, >=, <= behavior https://bugs.ruby-lang.org/issues/21921 * Author: cohen (Cohen Carlisle) * 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 ---------------------------------------- Hash seems to have very inconsistent behavior for `==`, `>=`, and `<=`. Given that below h1 == h2 is `false` and that they have the same number of keys, I would expect `<=` and `>=` to also be `false`. However, surprisingly `h1 <= h2` and `h2 >= h1` are `true`, while all other permutations are `false`. ``` h1 = {}.compare_by_identity.tap { _1["one"] = 1 } # => {"one" => 1} h2 = {"one" => 1} # => {"one" => 1} h1 == h2 # => false h2 == h1 # => false h1 >= h2 # => false h1 <= h2 # => true h2 >= h1 # => true h2 <= h1 # => false ``` -- https://bugs.ruby-lang.org/

5 7

[ruby-core:125046] [Ruby Feature#17056] Array#index: Allow specifying the position to start search as in String#index
by matz (Yukihiro Matsumoto) 17 Mar '26

17 Mar '26

Issue #17056 has been updated by matz (Yukihiro Matsumoto). I think it's good to add an offset: keyword argument to `Array#index` and `Array#rindex`, for consistency with `String#index` and `String#rindex`. As for `Array#find_index`, I think we should add `offset:` there as well, keeping it in sync with `Array#index`. We will leave `Enumerable#find_index` untouched, since adding an offset to a lazy enumerable feels unnatural. We have no plan to add an end index for now. Matz. ---------------------------------------- Feature #17056: Array#index: Allow specifying the position to start search as in String#index https://bugs.ruby-lang.org/issues/17056#change-116745 * Author: TylerRick (Tyler Rick) * Status: Open ---------------------------------------- I have a use case of finding the first matching line within a given section in a file. After finding the line number of the start of the section, I want to find the first match after that line. My workaround for now is to use `with_index`: ```ruby lines = pathname.read.lines section_start_line = lines.index {|line| line.start_with?(/#* #{section_name}/) } lines.index.with_index {|line, i| i > section_start_line && line.include?(sought) } ``` I'd like to do it in a more concise way using a feature of `Array#index` that I propose here, which is analogous to `String#index`. If the second parameter of `String#index` is present, it specifies the position in the string to begin the search: ```ruby 'abcabc'.index('a') # => 0 'abcabc'.index('a',2) # => 3 ``` I would expect to also be able to do: ```ruby 'abcabc'.chars.index('a') # => 0 'abcabc'.chars.index('a', 2) ``` Using such feature, I would be able to do: ```ruby lines.index(sought, section_start_line) ``` This would give Ruby better parity with other programming languages like Python: ```python >>> list('abcabc') ['a', 'b', 'c', 'a', 'b', 'c'] >>> list('abcabc').index('a') 0 >>> list('abcabc').index('a', 2) 3 ``` ## End index We can further think of an optional parameter to specify the position to end the search. The following languages allow specifying both start and end indexes: - [Python](https://docs.python.org/3/tutorial/datastructures.html) - [C#](https://docs.microsoft.com/en-us/dotnet/api/system.array.indexof?view=n… Ruby's `String#index` does not have one, so we could make a separate proposal to add `end` to both methods at the same time. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122847] [Ruby Feature#21520] Feature Proposal: Enumerator::Lazy#peek
by nuzair46 (Nuzair Rasheed) 17 Mar '26

17 Mar '26

Issue #21520 has been reported by nuzair46 (Nuzair Rasheed). ---------------------------------------- Feature #21520: Feature Proposal: Enumerator::Lazy#peek https://bugs.ruby-lang.org/issues/21520 * Author: nuzair46 (Nuzair Rasheed) * Status: Open ---------------------------------------- # Abstract Add a #peek method to Enumerator::Lazy that allows observing each element in a lazy enumeration pipeline without modifying or consuming the stream. # Background Ruby provides Enumerator::Lazy for efficient lazy stream processing. However, unlike languages such as Java, it lacks a clean way to inspect intermediate elements during lazy evaluation. Currently, developers must misuse .map for side effects, example: ```rb (1..).lazy.map { |x| puts x; x }.select(&:even?).first(3) ``` This is semantically incorrect and confusing, since .map implies transformation, not observation. # Proposal Introduce Enumerator::Lazy#peek, which yields each item to a block and returns the item unmodified, similar to Object#tap, but in a lazy stream: ```rb (1..).lazy .peek { |x| puts "saw: #{x}" } .select(&:even?) .first(3) ``` This would be equivalent to: ```rb lazy.map { |x| block.call(x); x } ``` but with improved semantic clarity. # Use cases • Debugging lazy enumerators without breaking the chain • Logging or instrumentation in pipelines • Educational / demo use for showing lazy evaluation step-by-step • Cleaner replacement for map { puts x; x } hacks Example: ```rb data = (1..).lazy .peek { |x| puts "got #{x}" } .select(&:even?) .first(5) ``` result: ```rb got 1 got 2 got 3 got 4 got 5 ``` And return [2, 4, 6, 8, 10] # Discussion #peek is a minimal, non-breaking addition that improves clarity and idiomatic usage of Enumerator::Lazy. It avoids abusing .map for observation and is familiar to developers from other languages. #peek is also not needed for other enumerators where .tap or .each can do the job. It mirrors Java’s .stream().peek(...) and makes Ruby’s lazy enumeration more expressive and readable. # See also • [Java Stream.peek](https://docs.oracle.com/javase/8/docs/api/java/util/stream/Str… I would be glad to work on this and make a PR. Thank you. -- https://bugs.ruby-lang.org/

4 14

[ruby-core:124892] [Ruby Feature#21929] Add configure script options for instrumenting Rust builds
by jprokop (Jarek Prokop) 17 Mar '26

17 Mar '26

Issue #21929 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Feature #21929: Add configure script options for instrumenting Rust builds https://bugs.ruby-lang.org/issues/21929 * Author: jprokop (Jarek Prokop) * Status: Open ---------------------------------------- Ruby at this moment optionally includes Rust bits. Right now this touches mostly YJIT and ZJIT. Rust is a compiled language with various compile flags at various stages and approaches. My ask is to provide a way to instrument compilation similarly as with C at the moment so that packagers and distributions can be fully and easily compliant with their guidelines on compilation flags. Currently, for production build of Ruby, `rustc` tool is used, which is instrumented differently from `cargo` in debug builds. In my PR motivated by the described goal: https://github.com/ruby/ruby/pull/15695 I have focused on providing `rustc` with our distribution flags, during the PR it was mentioned that there are flags related to security https://github.com/ruby/ruby/pull/15695#discussion_r2663651764 that should be present even when providing distribution flags. This is not too different from C, as there are also security flags, such as configure script enabling the arm64's BTI and PAC when possible. `rustc` of version 1.92, at the time of the PR uses the last mention of a flag. Ideally `rustc` would know `RUSTFLAGS`, but as far as I can tell, the enviroment variable only affects `cargo`. In Fedora the current guidance recommends using `%build_rustflags` https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_compiler_f… which expands to `-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes --cap-lints=warn` The best result is each part of Rust in Ruby would receive the flags defined during `configure` time. In cases where complication flags should conflict, in Fedora distribution flags take precedence: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_building_w… -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125041] [Ruby Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 17 Mar '26

17 Mar '26

Issue #6012 has been updated by Eregon (Benoit Daloze). Right, I will make a proposal for `Ruby::SourceLocation`/`Ruby::CodeLocation` or so. I hope it can be approved quickly without taking more time. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-116739 * Author: rogerdpack (Roger Pack) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125039] [Ruby Feature#21822] Expose Return Value in the ensure Block
by matz (Yukihiro Matsumoto) 17 Mar '26

17 Mar '26

Issue #21822 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Rejected Thank you for the feedback. I understand the aesthetic appeal, but "cleaner" is subjective, and the existing pattern is already idiomatic Ruby with no real cognitive overhead. More importantly, "purely additive" does not mean cost-free. Every new syntax must be defined precisely, documented, and handle edge cases correctly. As nobu noted in #3, the semantics when an exception is raised are not obvious, which suggests the concept has rough edges that outweigh the cosmetic benefit. Matz. ---------------------------------------- Feature #21822: Expose Return Value in the ensure Block https://bugs.ruby-lang.org/issues/21822#change-116736 * Author: artemb (Artem Borodkin) * Status: Rejected ---------------------------------------- I'd like to propose a simple feature that allows easy access to the return value inside an ensure block. ```ruby begin # ... ensure => ret # ret is nil if an exception is raised LOGGER.debug "return value: #{ret}" end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125038] [Ruby Feature#6012] Proc#source_location also return the column
by matz (Yukihiro Matsumoto) 17 Mar '26

17 Mar '26

Issue #6012 has been updated by matz (Yukihiro Matsumoto). Thank you, @eregon, for the thorough analysis and for pushing this feature forward with such persistence over the years. I have reconsidered my position. Although I approved this change, and it has been in master for a year, I now believe extending the existing `source_location` return value from 2 elements to 5 is the wrong approach. The information itself is not undesirable, but the API design is unsound. The evidence in #note-43 is difficult to dismiss. The idiom `obj.source_location.last` is pervasive across the gem ecosystem, not only in test files but in production library code. Returning `end_column` from `.last` instead of `lineno` is an unexpected semantic shift. Even if every well-maintained gem has been patched, user application code in the wild cannot be audited or fixed centrally. This is the kind of silent, hard-to-debug breakage that I find particularly regrettable. I understand @eregon 's argument that the breakage is small in practice, and that the feature has been available in previews without major complaints. But my concern is not just about breakage that has already surfaced. It is also about breakage that has not surfaced yet, in private codebases and unmaintained gems. More fundamentally, `source_location` was designed as a 2-element tuple, and that contract is now baked deeply into the ecosystem. Extending it is technically a compatible addition, but idiomatically it is a breaking change for any code that treats the array positionally. Therefore, I am reverting this change for now. I would like to introduce the additional information through a new, dedicated API instead, something like `source_range` returning an object with `start_line`, `start_column`, `end_line`, `end_column` as named attributes, or a `Ruby::SourceLocation` class as discussed in related issues. This approach keeps `source_location` stable and backward-compatible, makes the richer information explicitly opt-in, and allows us to design the API properly (e.g., bytes vs. characters, what to expose for `Binding`, etc.) without rushing. I know this is frustrating after 14 years and two approvals. I am sorry for the back-and-forth. The use cases are real and I want to support them, just through a cleaner API that does not carry this compatibility risk. Matz. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-116735 * Author: rogerdpack (Roger Pack) * Status: Closed * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124797] [Ruby Feature#21875] Handling of trailing commas in lambda parameters
by Earlopain (Earlopain _) 17 Mar '26

17 Mar '26

Issue #21875 has been reported by Earlopain (Earlopain _). ---------------------------------------- Feature #21875: Handling of trailing commas in lambda parameters https://bugs.ruby-lang.org/issues/21875 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- https://bugs.ruby-lang.org/issues/19107 was accepted, which is about trailing commands in method definitions. lambdas were not explicitly mentioned but I wanted to confirm how they should behave with a trailing comma. Or if a trailing comma should even be accepted for them. It's not clear to me since lambdas sometimes behave like blocks and sometimes more like methods. `->(...) {}` for example is syntax invalid (same as in blocks) but they do check their arity with blocks don't do. If a trailing comma is accepted it can either * be implicit splat like in `foo do |bar,|; end` or `foo do |bar|; end`. It would also mean that the trailing comma is only allowed after a positional argument. * Just be ignored and be accepted in most places like for method definitions. The first option would be rather useless in regards to https://bugs.ruby-lang.org/issues/19107 when you just want to add the comma for cleaner diffs. But I guess for lambdas this happens very rarely anyways. -- https://bugs.ruby-lang.org/

5 5