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

[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

[ruby-core:124677] [Ruby Feature#21861] C API: expose `ruby_xfree_sized`, `ruby_xrealloc_sized`, etc
by byroot (Jean Boussier) 17 Mar '26

17 Mar '26

Issue #21861 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21861: C API: expose `ruby_xfree_sized`, `ruby_xrealloc_sized`, etc https://bugs.ruby-lang.org/issues/21861 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context For the longest time now, Ruby had internal API such as `ruby_sized_xfree`, `ruby_sized_xrealloc` and `ruby_sized_xrealloc2`. These are identical to their non-sized counterpart, expect they accept the original size of the buffer being free or reallocated. This information is then fed to the garbage collector to improve heuristics as to when GC should run (`malloc_increase_bytes` and `oldmalloc_increase_bytes`). When the old buffer size isn't provided, Ruby tries to obtain it via `malloc_usable_size`, which isn't available on all platform, but also isn't quite correct as it's generally over reporting. It also happen to be quite slow on some allocators, such as `mallocng`, the allocator used by `muslc` hence by alpine linux. ### C23 `free_sized` The C23 standard added the `free_sized(void *ptr, size_t oldsize)` API, and it's now available in `glibc 2.43`, other popular allocators like `jemalloc` and `tcmalloc` also have it since a few years. Original spec: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2699.htm Interestingly the standard doesn't include a `realloc_sized` API, I'm unsure why. For most allocators, providing the size to `free_sized` allow to skip some step and provide a speedup. I've read some 30% claims, but I haven't benchmarked myself. One thing to note is that according to the standard, passing the wrong size is undefined behavior: > If ptr is the result obtained from a call to `malloc(size)`, `realloc(old_ptr, size)`, or `calloc(nmemb, memb_size)`, where `nmemb * memb_size` is equal to `size`, this function behaves equivalently to `free(ptr)`. Otherwise, the result is undefined. Recently I refactored most internal calls to `xfree` inside Ruby itself to use `ruby_sized_xfree` instead, and would like to have it use `free_sized` when available. Also when `RUBY_DEBUG` is defined, `xmalloc` does register the original allocated size, and enforce that the size provided to `ruby_sized_xfree` does match. This allowed to uncover several small bugs, notably in `string.c` where we'd sometime end up with an incorrect `capacity` attribute after an encoding change. ### Benefits Aside from the performance gains on some allocators, and the gains from having more accurate GC statistics, I believe these sized interfaces help ensure correctness of the code. Except for a few exceptions, most code dealing with a buffer must know its size to avoid going out of bound, so providing it to `ruby_xfree_sized` allows to assert the size was correctly tracked in debug builds. I also believe ASAN or UBSAN are likely to also enforce this soon (if they don't already), so it could help catch more bugs early. ### Proposal I would like to expose these sized APIs to C extensions, so that they can benefit from it as well: - `void ruby_xfree_sized(void *ptr, size_t oldsize)` - `void *ruby_xrealloc_sized(void *ptr, size_t newsize, size_t oldsize)` - `void *ruby_xrealloc2_sized(void *ptr, size_t n, size_t size, size_t old_n)` I also think I would be useful to expose the corresponding macros: - `RB_REALLOC_SIZED_N` - `RB_SIZED_FREE` (shorthand to free a simple pointer: `ruby_xfree_sized(ptr, sizeof(*ptr))`). - `RB_SIZED_FREE_N` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124877] [Ruby Misc#21924] Register a Maven artifact for JVM-related libraries
by headius (Charles Nutter) 17 Mar '26

17 Mar '26

Issue #21924 has been reported by headius (Charles Nutter). ---------------------------------------- Misc #21924: Register a Maven artifact for JVM-related libraries https://bugs.ruby-lang.org/issues/21924 * Author: headius (Charles Nutter) * Status: Open ---------------------------------------- For the Prism project, I am working toward having published artifacts for JVM users (like JRuby or TruffleRuby). Publishing these packages will make it much easier for us to support Prism in JRuby, both as our interal Ruby parser and as an installable gem. We do not copy sources into our repository, and *must* be able to point a release artifact that can be tracked through supply chain tooling etc. In order to publish artifacts, we need to register the `org.ruby-lang` namespace with Sonatype, maintainers of Maven Central (the primary source of JVM-based software packages). The process is detailed here: https://central.sonatype.org/register/namespace/ The simple description of the process follows: 1. Register an account on Sonatype. I already have one for JRuby and other JVM projects. 2. Register the namespace. I have posted an initial request for the `org.ruby-lang` namespace. 3. Verify the namespace. This requires DNS help as described on the above page and in the screenshot below. 4. Publish artifacts to the namespace. The first artifact would be named something like `prism-ruby-parser`, so its "coordinates" would be `org.ruby-lang:prism-ruby-parser:0.0.1`. I need: * Someone who can update the DNS entry to include the key needed by Sonatype for verification. * A list of users who should potentially have push rights for this namespace. I don't expect anyone but JRuby committers and possibly TruffleRuby committers will be using this namespace. For the moment I will be publishing the artifacts I need under the `org.jruby` namespace, but because there's very little JRuby-specific logic in the core Prism JVM wrapper library, I would prefer to publish it under the `org.ruby-lang` domain. -- https://bugs.ruby-lang.org/

2 6

[ruby-core:124935] [Ruby Bug#21946] `and?` predicate confused for leading `and` keyword
by Earlopain (Earlopain _) 16 Mar '26

16 Mar '26

Issue #21946 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21946: `and?` predicate confused for leading `and` keyword https://bugs.ruby-lang.org/issues/21946 * Author: Earlopain (Earlopain _) * Status: Open * Assignee: prism * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- Originally reported at https://github.com/ruby/prism/pull/3337#issuecomment-4004880188 ```sh $ ruby -ce $'foo\nand?' ruby: -e:2: syntax errors found (SyntaxError) 1 | foo > 2 | and? | ^ expected an expression after `?` in the ternary operator | ^ unexpected '?'; expected an expression after the operator | ^ unexpected end-of-input, assuming it is closing the parent ternary expression ``` Same for `and!` and `or` . parse.y is not impacted Fix in https://github.com/ruby/prism/pull/3966 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120819] [Ruby master Bug#21097] `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism
by tompng (tomoya ishida) 16 Mar '26

16 Mar '26

Issue #21097 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21097: `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism https://bugs.ruby-lang.org/issues/21097 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-27T08:19:32Z master c3c7300b89) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ruby x = a rescue b in c (x = (a rescue b)) in c # parse.y, prism(ruby 3.4) x = (a rescue (b in c)) # prism(ruby 3.5) ~~~ ~~~ruby def f = a rescue b in c #=> true(parse.y), :f(prism) (def f = (a rescue b)) in c # parse.y def f = (a rescue (b in c)) # prism ~~~ There is no difference between prism and parse.y parsing these codes ~~~ruby a rescue b in c # a rescue (b in c) x = a rescue b # x = (a rescue b) x = b in c # (x = b) in c def f = a rescue b # def f = (a rescue b) def f = b in c # (def f = a) in b ~~~ -- https://bugs.ruby-lang.org/

9 12

[ruby-core:124934] [Ruby Bug#21945] Ripper lexes newline between identifier and `and?` as ignored newline
by Earlopain (Earlopain _) 16 Mar '26

16 Mar '26

Issue #21945 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21945: Ripper lexes newline between identifier and `and?` as ignored newline https://bugs.ruby-lang.org/issues/21945 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: DONTNEED, 4.0: UNKNOWN ---------------------------------------- ```rb Ripper.lex("foo\nand?") => [[[1, 0], :on_ident, "foo", CMDARG], [[1, 3], :on_ignored_nl, "\n", CMDARG], [[2, 0], :on_ident, "and?", ARG]] ``` Presumably this is because until the `?` is encountered, it is considered syntax as introduced in https://bugs.ruby-lang.org/issues/20925. The same is true for `and!` and `or`. If any other character is encountered, it lexes correctly like in `foo\nandbar`. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124848] [Ruby Bug#21917] Unable to build 4.0.1 on AIX 7.2
by mhashizume (Michael Hashizume) 16 Mar '26

16 Mar '26

Issue #21917 has been reported by mhashizume (Michael Hashizume). ---------------------------------------- Bug #21917: Unable to build 4.0.1 on AIX 7.2 https://bugs.ruby-lang.org/issues/21917 * Author: mhashizume (Michael Hashizume) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I'm attempting to build Ruby 4.0.1 on AIX 7.2. We have had successful builds of previous versions of Ruby on this platform, but are starting to see an issue when using miniruby to build Ruby: ``` shell ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems -r./powerpc64-aix7.2.0.0-fake ./tool/rbinstall.rb --make="gmake" --dest-dir="" --extout=".ext" --ext-build-dir="./ext" --mflags="-j3 --jobserver-auth=fifo:/tmp//GMfifo9306586" --make-flags=" -j3 --jobserver-auth=fifo:/tmp//GMfifo9306586" --data-mode=0644 --prog-mode=0755 --installed-list .installed.list --mantype="man" --install=all --exclude=doc /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in 'Kernel#require': false() function is unimplemented on this machine (NotImplementedError) from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in 'Kernel#eval' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from ./tool/rbinstall.rb:25:in 'Kernel#require' from ./tool/rbinstall.rb:25:in '<main>' ``` I'm not sure where the NotImplementedError is coming from, and when looking at the `truss` output from miniruby, I see a ENOTTY when miniruby attempts to load monitor.so: ```shell accessx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0/monitor.so", 0, 0) = 0 statx("/", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0/monitor.so", 0x0FFFFFFFFFFFA680, 176, 011) = 0 __ksetjmp(0x0000000110019F88, 0x09000000026845A8, 2, 0x000000011001A1D8, 0x0FFFFFFFFFFFB790, 0x0000000022242202, 0x000000011011A658, 0x09000 00000260348) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0/monitor.so", 0x0FFFFFFFFFFFB800, 176, 0) = 0 kioctl(2, 22528, 0x0000000000000000, 0x0000000000000000) Err#25 ENOTTY /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in 'Kernel#require': false() function is unimplemented on this machine (NotImpl ementedError) from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in 'Kernel#eval' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from ./tool/rbinstall.rb:25:in 'Kernel#require' from ./tool/rbinstall.rb:25:in '<main>' ``` monitor.so is present in the path that miniruby is looking for it. Any pointers on where to start debugging this further or what changes in more recent versions of Ruby could have caused this would be greatly appreciated. Thank you! -- https://bugs.ruby-lang.org/

3 4

[ruby-core:124906] [Ruby Bug#21934] Prism and parse.y inconsistency in command call used with pattern match
by tompng (tomoya ishida) 16 Mar '26

16 Mar '26

Issue #21934 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21934: Prism and parse.y inconsistency in command call used with pattern match https://bugs.ruby-lang.org/issues/21934 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.1.0dev (2026-03-03T16:19:28Z master e30b5a06dc) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- These are syntax error in both parse.y and in Prism ~~~ruby a x in pattern a x: in pattern a &x in pattern a *x => pattern a x: => pattern a &x => pattern ~~~ These are all syntax error in parse.y, all syntax valid in Prism ~~~ruby a.b x in pattern a.b x: in pattern a.b &x in pattern a.b *x => pattern a.b x: => pattern a.b &x => pattern ~~~ I think this is related to https://github.com/ruby/prism/issues/3558, `A.print message:\nin 'BAR'` inside case-in was parsed as `(A.print message:) in 'BAR'`. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:124443] [Ruby Bug#21828] An incorrect warning message related to `benchmark` is shown when using `benchmark-ips`
by y-yagi (Yuji Yaginuma) 16 Mar '26

16 Mar '26

Issue #21828 has been reported by y-yagi (Yuji Yaginuma). ---------------------------------------- Bug #21828: An incorrect warning message related to `benchmark` is shown when using `benchmark-ips` https://bugs.ruby-lang.org/issues/21828 * Author: y-yagi (Yuji Yaginuma) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Descrition When using `benchmark-ips` gem with Ruby 4.0.0, the warning related to `benchmark` gem is shown. ## Step to reproduce ```ruby # Gemfile # frozen_string_literal: true source "https://rubygems.org" gem "benchmark-ips" ``` ```ruby # script.rb require "benchmark/ips" ``` ```text $ bundle exec ruby -v script.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] script.rb:1: warning: benchmark/ips is found in benchmark, which is not part of the default gems since Ruby 4.0.0. You can add benchmark to your Gemfile or gemspec to fix this error. ``` ## Expected behavior The warning for `benchmark` isn't shown when using `benchmark-ips`. -- https://bugs.ruby-lang.org/

4 13