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

[ruby-core:124913] [Ruby Bug#21938] [sec-test] html-upload-1772572676
by idorcinoir7h (Idor Agent) 03 Mar '26

03 Mar '26

Issue #21938 has been reported by idorcinoir7h (Idor Agent). ---------------------------------------- Bug #21938: [sec-test] html-upload-1772572676 https://bugs.ruby-lang.org/issues/21938 * Author: idorcinoir7h (Idor Agent) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- html upload probe ---Files-------------------------------- probe.html (73 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124912] [Ruby Bug#21936] [sec-test] file-upload-1-1772572612
by idorcinoir7h (Idor Agent) 03 Mar '26

03 Mar '26

Issue #21936 has been reported by idorcinoir7h (Idor Agent). ---------------------------------------- Bug #21936: [sec-test] file-upload-1-1772572612 https://bugs.ruby-lang.org/issues/21936 * Author: idorcinoir7h (Idor Agent) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- upload test 1 ---Files-------------------------------- normal-probe.txt (14 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124911] [Ruby Bug#21937] [sec-test] file-upload-2-1772572613
by idorcinoir7h (Idor Agent) 03 Mar '26

03 Mar '26

Issue #21937 has been reported by idorcinoir7h (Idor Agent). ---------------------------------------- Bug #21937: [sec-test] file-upload-2-1772572613 https://bugs.ruby-lang.org/issues/21937 * Author: idorcinoir7h (Idor Agent) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- upload test 2 ---Files-------------------------------- traversal-probe.txt (14 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124909] [Ruby Bug#21935] XSSD_STORE_1 <svg id=XSSD_STORE_1 onload=alert(1)>
by idorcinoir7h (Idor Agent) 03 Mar '26

03 Mar '26

Issue #21935 has been reported by idorcinoir7h (Idor Agent). ---------------------------------------- Bug #21935: XSSD_STORE_1 <svg id=XSSD_STORE_1 onload=alert(1)> https://bugs.ruby-lang.org/issues/21935 * Author: idorcinoir7h (Idor Agent) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- DESC XSSD_STORE_1 <svg id=XSSD_STORE_1 onload=alert(1)> -- https://bugs.ruby-lang.org/

1 1

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

03 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/

1 0

[ruby-core:124419] [Ruby Bug#21827] Deprecating Ripper
by Eregon (Benoit Daloze) 03 Mar '26

03 Mar '26

Issue #21827 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21827: Deprecating Ripper https://bugs.ruby-lang.org/issues/21827 * Author: Eregon (Benoit Daloze) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I think it is time to consider deprecating `Ripper`. [Matz has agreed that going forward the official parser API for Ruby will be the Prism API](https://railsatscale.com/2024-04-16-prism-in-2024/) so it's clear the official Ruby parsing API is the Prism API. `Ripper` while being currently supported on CRuby, JRuby and TruffleRuby (partially) has a significant maintenance overhead. For CRuby, it roughly doubles the number of lines in `parse.y` and adds lots of `#ifdef RIPPER`/`#ifndef RIPPER` which makes it really hard to follow. For JRuby it's many thousands of lines of code to maintain just for that: https://github.com/jruby/jruby/tree/master/core/src/main/java/org/jruby/ext… For TruffleRuby, `ripper` is by far the most difficult C extension to support as it relies on many internal functions. When an internal function is used by ripper is missing it kills the entire process. On every update of `RUBY_VERSION` in TruffleRuby, the biggest amount of time is spent dealing with Ripper, which feels as a result like a major hack. It could be possible to implement Ripper based on Prism, in fact there is [some support for that](https://github.com/ruby/prism/blob/main/docs/ripper_translation.md), but the fact the Ripper API is rather unstable means it's hard to be compatible, and currently the translation layer [relies on original ripper for some things](https://github.com/ruby/prism/blob/e0e5e68acbed98a6b4e4e77b9b52b448…. It's also worth noting that [`Ripper.sexp` is 2.75x slower than `Prism.parse`](https://eregon.me/blog/2024/10/27/benchmarking-ruby-parsers.html#parsing-and-not-walking), while providing a much worse API (widely recognized as such, e.g. `Ripper.sexp("def m = 42")` vs `Prism.parse("def m = 42")`, lots of `nil` with unclear meaning in `Ripper`). So from a new code perspective there seems to be very little value to use `Ripper`. `Ripper` has lexing via `Ripper.lex`, which can be replaced by `Prism::lex_compat`. I think we should start to deprecate `Ripper`. The advantages of deprecating it are: * Make it clear that this API should not be used in new code * Encourage the usages to migrate to the Prism API, which is stable, officially supported, designed with many people to be usable and convenient for every parsing/tooling usage, etc. * Improve portability of Ruby code between Ruby implementations (given Ripper is not fully compatible between Ruby implementations) I propose to deprecate Ripper in 4.1. I'm not sure when it would be appropriate to remove it given it's a more established API, maybe in 4.2, 4.3? -- https://bugs.ruby-lang.org/

5 8

[ruby-core:124901] [Ruby Bug#21931] GC Crash in `String#%` (backport 726205b354d1068147719fb42e1de743f1838ef1)
by byroot (Jean Boussier) 03 Mar '26

03 Mar '26

Issue #21931 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21931: GC Crash in `String#%` (backport 726205b354d1068147719fb42e1de743f1838ef1) https://bugs.ruby-lang.org/issues/21931 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.2: WONTFIX, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Reproduction ```ruby GC.stress = true class Args def to_ary Array.new(64) { "x" * 1024 } end end fmt = "%s" * 64 100_000.times do fmt % Args.new end ``` Patch that should be backported https://github.com/ruby/ruby/commit/726205b354d1068147719fb42e1de743f1838ef1 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:124891] [Ruby Misc#21928] Prism backport handling
by Earlopain (Earlopain _) 03 Mar '26

03 Mar '26

Issue #21928 has been reported by Earlopain (Earlopain _). ---------------------------------------- Misc #21928: Prism backport handling https://bugs.ruby-lang.org/issues/21928 * Author: Earlopain (Earlopain _) * Status: Open * Assignee: prism ---------------------------------------- https://bugs.ruby-lang.org/issues/21927 got marked for backport for 4.0 and 3.4. It's a trivial fix but since prism is a gem, ruby should contain a released version of prism only. 3.4 in particular currently contains prism 1.5.2. Backporting to that version would require at least two changes in `ruby/ruby` because of changes in prism itself. So it is not as easy as just `tool/sync_default_gems`. Currently the practise has been to just backport the lastest prism version but personally I don't think that is sustainable. At best it causes more work than necessary and at worst you get fresh new bugs in what is supposed to be a stable ruby release. https://github.com/ruby/prism/pull/3231 is a good example of something that should not be backported to all maintained ruby versions when it gets merged. I propose to maintain stable branches for prism. Branch maintainers can simply cherry-pick what they think should be backported and prism takes care of releasing the appropriate versions, branched from the version that the stable ruby version originally shipped with. As far as I'm aware, that's also the strategy other gems go with. It happens less frequent now that many gems are no longer standard gems but openssl for example has branches for this purpose https://github.com/ruby/openssl/branches. I'm not sure how it handles versions, some gems I see do `1.2.3.4` which doesn't exactly follow semver, but it should possible to do it by following semver. What do you think @kddnewton? I know that so far you've wanted to do the latest stable version but I think prism is too intertwined with ruby itself for the current approach. Especially now that there are two stable branches that ship with prism it doesn't get easier. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124885] [Ruby Bug#21925] Prism misparses standalone "in" pattern matching in "case/in"
by knu (Akinori MUSHA) 02 Mar '26

02 Mar '26

Issue #21925 has been reported by knu (Akinori MUSHA). ---------------------------------------- Bug #21925: Prism misparses standalone "in" pattern matching in "case/in" https://bugs.ruby-lang.org/issues/21925 * Author: knu (Akinori MUSHA) * Status: Open * Target version: 4.1 * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin23] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Prism misparses standalone `in` pattern matching in `case/in` when the left-hand side is a method call with a dot receiver ## Summary When a standalone `expr in pattern` one-line pattern match appears inside a `case/in` branch, and `expr` is a method call with a dot receiver (for example, `obj.method`), Prism incorrectly parses `in pattern` as a new branch of the outer `case/in` instead of treating it as a `MatchPredicateNode`. The parse.y parser handles this case correctly. ## Reproduction ``` $ ruby -v ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin23] ``` It also reproduces on Ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [arm64-darwin25]. ### Minimal script ```ruby x = "x" case x in Integer nil in String p :before x.itself in String p :after end ``` ### Command output ``` $ ruby -e ' x = "x" case x in Integer nil in String p :before x.itself in String p :after end ' :before $ ruby --parser=parse.y -e ' x = "x" case x in Integer nil in String p :before x.itself in String p :after end ' :before :after ``` ### Expected behavior (parse.y) Both `:before` and `:after` are printed. `x.itself in String` is parsed as a standalone pattern match (predicate) inside the `in String` branch. ### Actual behavior (Prism) Only `:before` is printed; `p :after` is never executed. ## Analysis Prism splits `x.itself in String` at the `in` keyword, treating `x.itself` as the last statement of the `in String` branch and `in String` as a third branch of the outer `case/in`. The following script shows how each parser interprets the `case/in` branches: ```ruby code = <<~RUBY x = "x" case x in Integer nil in String x.itself in String p :after end RUBY # Prism require "prism" ast = Prism.parse(code).value.statements.body[1] puts "Prism: conditions: #{ast.conditions.length}" ast.conditions.each_with_index do |c, i| pat = c.pattern name = pat.respond_to?(:name) ? pat.name : pat.class stmts = c.statements&.body&.map { |s| s.class.name.split("::").last } || [] puts " in[#{i}]: pattern=#{name}, body=#{stmts}" end # parse.y (Ripper) require "ripper" sexp = Ripper.sexp(code) case_node = sexp[1][1] def count_in_branches(node) return [] unless node.is_a?(Array) && node[0] == :in pattern_node = node[1] body = node[2] || [] name = pattern_node.is_a?(Array) && pattern_node[1].is_a?(Array) ? pattern_node[1][1] : pattern_node[1] stmts = body.map { |s| s[0].to_s } [{ pattern: name, body: stmts }] + count_in_branches(node[3]) end branches = count_in_branches(case_node[2]) puts "\nparse.y (Ripper): conditions: #{branches.length}" branches.each_with_index do |b, i| puts " in[#{i}]: pattern=#{b[:pattern]}, body=#{b[:body]}" end ``` Output (run with `ruby --parser=parse.y` so Ripper uses parse.y): ``` Prism: conditions: 3 in[0]: pattern=Integer, body=["NilNode"] in[1]: pattern=String, body=["CallNode"] in[2]: pattern=String, body=["CallNode"] parse.y (Ripper): conditions: 2 in[0]: pattern=Integer, body=["var_ref"] in[1]: pattern=String, body=["case", "command"] ``` Prism reports 3 branches, while parse.y reports 2. In the parse.y result, `in[1]` correctly contains both the inner expression (`x.itself in String` parsed as a standalone pattern match) and the `command` (`p :after`). In the Prism result, `x.itself` becomes the sole body of `in[1]`, and `in String` is misinterpreted as a new `in[2]` branch of the outer `case`. ## Consideration From experimentation, the issue appears to be triggered only when all of the following are true: 1. The outer `case/in` has at least two `in` branches before the affected branch. 2. The standalone `in` expression uses a dot-receiver method call as its left-hand side, such as `obj.method in Pattern`. Conditions where this behavior is not observed: - If the expression is a receiver-less call, such as `f(x) in Pattern`, the parser keeps it as a standalone pattern match. - If the receiver expression is parenthesized, such as `(obj.method) in Pattern`, the parser keeps it as a standalone pattern match. - If you assign first, such as `y = obj.method; y in Pattern`, the parser keeps it as a standalone pattern match. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:124893] [Ruby Bug#14582] Unable to use `method__entry` and `method_return` tracing probes since 2.5
by jacobcarlborg (Jacob Carlborg) 01 Mar '26

01 Mar '26

Issue #14582 has been updated by jacobcarlborg (Jacob Carlborg). I've created a pull request to fix this: https://github.com/ruby/ruby/pull/16084. ---------------------------------------- Bug #14582: Unable to use `method__entry` and `method_return` tracing probes since 2.5 https://bugs.ruby-lang.org/issues/14582#change-116552 * Author: guilhermereiscampos (Guilherme Reis Campos) * Status: Open * ruby -v: 2.5 * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Hi, I am trying to use dtrace/systemtap probes and not being able to use it after the 2.5. The 2.4 version works fine. I was hoping this was fixed on 2.6-preview, but apparently not (just downloaded dev and tested). I tried on OSX using dtrace and also on ubuntu (vagrant). ``` # test.rb class Foo def bar 100.times { "Bar" } end end foo = Foo.new foo.bar # test.stp probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__entry") # you will need to change this to your ruby path of your version. { printf("%s => %s.%s in %s:%d\n", thread_indent(1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__return") { printf("%s <= %s.%s in %s:%d\n", thread_indent(-1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } ``` dtrace was something similar to it. I was expecting to see this output: ``` # lots of calls # .... # then: 4090 ruby(9667): <= Gem::Specification.unresolved_deps in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/specification.rb:1298 4095 ruby(9667): => MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:197 4100 ruby(9667): => MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:247 4104 ruby(9667): <= MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:251 4109 ruby(9667): <= MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:204 4283 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 4303 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 0 ruby(9667): => Foo.bar in test.rb:3 16 ruby(9667): <= Foo.bar in test.rb:5 ``` (The output above is 2.4) my ruby (all versions that I tested) was install with rb-env: ``` RUBY_CONFIGURE_OPTS='--enable-dtrace --disable-install-doc' rbenv install 2.5.0 ``` I am happy to provide details if required. I'd also be happy to fix it if I have guidance. Thanks, -- https://bugs.ruby-lang.org/

1 0