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

[ruby-core:121451] [Ruby Bug#21201] Performance regression when defining methods inside `refine` blocks
by alpaca-tc (Hiroyuki Ishii) 07 Apr '25

07 Apr '25

Issue #21201 has been reported by alpaca-tc (Hiroyuki Ishii). ---------------------------------------- Bug #21201: Performance regression when defining methods inside `refine` blocks https://bugs.ruby-lang.org/issues/21201 * Author: alpaca-tc (Hiroyuki Ishii) * Status: Open * ruby -v: 3.3.7, 3.4.2, 3.5.0 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- After the change introduced in [PR #10037](https://github.com/ruby/ruby/pull/10037), a significant performance regression has been observed when defining methods within refine blocks. The PR correctly fixes a bug where `callcache` invalidation was missing when methods are defined inside a refinement. To fix this, it now invokes [`rb_clear_all_refinement_method_cache()`](https://github.com/ruby/ruby/blob/752a1d785475d1950b33c7d77b289a6a3a753f02/vm_method.c#L439-L443) at the time of method definition within `refine`. However, this function performs a full object space traversal via `rb_objspace_each_objects`, making it extremely expensive. In our team's Rails application, refinements are used heavily. During application code reload (triggered in development mode), `rb_clear_all_refinement_method_cache()` is called 1425 times, 1142 of which originate via `rb_clear_method_cache()`. As a result, the code reload time has increased from **5 seconds** to **15 seconds** after the patch. Since reloading occurs every time the code changes, this degrades development experience severely. ### Reproduction script: ```ruby require "bundler/inline" gemfile(true) do source "https://rubygems.org" gem "benchmark-ips" end mod = Module.new klass = Class.new Benchmark.ips do |x| x.report(RUBY_VERSION) do mod.send(:refine, klass) do def call_1 = nil def call_2 = nil def call_3 = nil end end x.save! "/tmp/performance_regression_refine.bench" x.compare! end ``` ### Benchmark results: ``` Comparison: 3.2.7: 1500316.7 i/s 3.3.7: 158.0 i/s - 9496.46x slower 3.5.0: 124.6 i/s - 12041.43x slower 3.4.2: 119.5 i/s - 12553.50x slower ``` Related Slack discussion: https://ruby-jp.slack.com/archives/CLWSHA76V/p1741932018811539 I totally understand the necessity and value of the past PR that fixed the callcache bugs. That said, I was wondering if there might be any ideas to make it faster, or to handle the invalidation more efficiently. -- https://bugs.ruby-lang.org/

4 7

[ruby-core:116666] [Ruby master Bug#20255] Embedded arrays aren't moved correctly across ractors
by luke-gru (Luke Gruber) 07 Apr '25

07 Apr '25

Issue #20255 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #20255: Embedded arrays aren't moved correctly across ractors https://bugs.ruby-lang.org/issues/20255 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `ractor.send(ary, move: true)` works incorrectly because if `ary` is embedded, the new moved object doesn't populate its own embedded space, it uses the MovedObject's embedded space. example: ```ruby r = Ractor.new { inner_ary = receive values = {} values[:equal] = (inner_ary == ["",{},2,3,4,5,6]) values[:string] = inner_ary.to_s values } ary = [String.new,Hash.new,2,3,4,5,6] r.send(ary, move: true) r_values = r.take p r_values[:equal] p r_values[:string] # => false # => "[\"\", {}, 2, 2.0, 21747991570, String, 3]" ``` -- https://bugs.ruby-lang.org/

3 17

[ruby-core:120613] [Ruby master Bug#21027] `not()` receiver should be `nil`
by kddnewton (Kevin Newton) 06 Apr '25

06 Apr '25

Issue #21027 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21027: `not()` receiver should be `nil` https://bugs.ruby-lang.org/issues/21027 * Author: kddnewton (Kevin Newton) * Status: Open * Assignee: prism * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `not` has a 0-argument mode, and the behavior differs from that of parse.y: ``` % RBENV_VERSION=3.4.0 ruby --parser=parse.y -e 'p not()' true % RBENV_VERSION=3.4.0 ruby --parser=prism -e 'p not()' false ``` This is because Prism interprets `not()` as `self.!` where parse.y interprets it as `nil.!`. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120414] [Ruby master Bug#20984] ENV.inspect is not encoding aware
by nobu (Nobuyoshi Nakada) 02 Apr '25

02 Apr '25

Issue #20984 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20984: ENV.inspect is not encoding aware https://bugs.ruby-lang.org/issues/20984 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- ```console $ ruby -e 'ENV.clear; ENV["\u{3042}"] = "a"; p ENV.inspect.encoding' #<Encoding:BINARY (ASCII-8BIT)> ``` -- https://bugs.ruby-lang.org/

3 6

[ruby-core:121463] [Ruby Bug#21203] TestGc#test_gc_parameter_init_slots is flaky results
by hsbt (Hiroshi SHIBATA) 02 Apr '25

02 Apr '25

Issue #21203 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21203: TestGc#test_gc_parameter_init_slots is flaky results https://bugs.ruby-lang.org/issues/21203 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I faced `TestGc#test_gc_parameter_init_slots` failure at everyday. https://github.com/ruby/ruby/actions/runs/14120822712/job/39560620479 ``` 1) Failure: TestGc#test_gc_parameter_init_slots [/home/runner/work/ruby/ruby/src/test/ruby/test_gc.rb:549]: <2> expected but was <3>. ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:121465] [Ruby Bug#21204] `TestEtc#test_ractor_parallel` is still flaky result
by hsbt (Hiroshi SHIBATA) 02 Apr '25

02 Apr '25

Issue #21204 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21204: `TestEtc#test_ractor_parallel` is still flaky result https://bugs.ruby-lang.org/issues/21204 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- https://github.com/ruby/ruby/actions/runs/14121185441/job/39561623937?pr=13… ``` 1) Failure: TestEtc#test_ractor_parallel [/home/runner/work/ruby/ruby/src/test/etc/test_etc.rb:178]: pid 150540 killed by SIGABRT (signal 6) (core dumped) | [BUG] pthread_mutex_lock: Owner died (EOWNERDEAD) | ruby 3.5.0dev (2025-03-28T03:13:46Z pull/13004/merge 4cfbc634ea) +PRISM +GC[mmtk] [x86_64-linux] | | -- Control frame information ----------------------------------------------- | | malloc_consolidate(): unaligned fastbin chunk detected | | -- Threading information --------------------------------------------------- | Total ractor count: 1 ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121490] [Ruby Bug#21208] `Ractor#send(move: true)` allow moving objects that are on the stack, and used by C code.
by byroot (Jean Boussier) 01 Apr '25

01 Apr '25

Issue #21208 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21208: `Ractor#send(move: true)` allow moving objects that are on the stack, and used by C code. https://bugs.ruby-lang.org/issues/21208 * Author: byroot (Jean Boussier) * Status: Open * Assignee: ractor * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following script causes a crash: ```ruby rac = Ractor.new do Ractor.receive end hash = Hash[*50.times] hash.merge!(12 => 0, 14 => 0) do |key, old_val, new_val| if key == 12 rac.send(hash, move: true) end new_val end p rac.take ``` Contrary to previous crashes related to `send(move: true)`, I'm afraid this one is with the design of the feature itself, not just the implementation. If we allow objects to be moved, any C code that calls `rb_yield()` may cause memory corruption if one of the objects it uses is moved. I personally can't see any realistic solution to this. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121493] [Ruby Feature#15574] Prohibit to pass a block on super() implicitly
by headius (Charles Nutter) 31 Mar '25

31 Mar '25

Issue #15574 has been updated by headius (Charles Nutter). There's still a problem here when an "unused block" warning is emitted from native code. The current behavior is actually quite counter-intuitive. Take this example of extending `Array` and overriding `index`. ```ruby class MyArray def index(arg) yield super(arg) end end MyArray.new([1]).index(1) {p it} ``` On all recent versions of Ruby, this will warn: ``` $ cx 3.4 ruby -v blah.rb ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] blah.rb:3: warning: given block not used 0 ``` The only way to eliminate the warning is to explicitly *prevent* the block from being passed using `super(arg, &nil)`: ```ruby def index(arg) yield super(arg, &nil) end ``` I see in https://bugs.ruby-lang.org/issues/15554 that this special "implicit block" behavior for `super()` has been explicitly ignored for warning purposes, but there's clearly some problematic cases remaining here. We just addressed a user bug report where the native method warned even if no block was explicitly passed to `super()`: https://github.com/jruby/jruby/issues/8728 ---------------------------------------- Feature #15574: Prohibit to pass a block on super() implicitly https://bugs.ruby-lang.org/issues/15574#change-112514 * Author: ko1 (Koichi Sasada) * Status: Rejected * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- As described in [Feature #15554], `super()` (not `super`) pass the given block. ``` class C def foo p block_given? end end class C1 < C def foo super #=> true super() #=> true end end C1.new.foo{} ``` `super` (without parameters) passes all passed parameters so it is no surprise to pass given block. However, `super()` (with parameters. In this case, it passes 0 parameters) also pass given block implicitly. I'm not sure who use this behavior, but I think it is simple to prohibit such implicit block passing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121491] [Ruby Feature#18784] `FileUtils.rm_f` and `FileUtils.rm_rf` should not mask exceptions
by deivid 31 Mar '25

31 Mar '25

Issue #18784 has been updated by deivid (David Rodríguez). I realized I never replied to latest objections from @mame to this feature. My use case is to make sure temporary test files and folders are cleaned after each test, because if they are not cleaned the following tests may not work as expected, since they rely on starting with an empty tmp folder. I'm not sure if that's "1) delete target at all costs" or "2) delete target if possible". I think it's "2), but raise an error if not possible". The kind of swallowed issues I've run into in the past are things like: * Keyword vs positional parameter error due to accidentally using a version of FileUtils not supported by my version of Ruby. * ENAMETOOLONG errors due to a bug in Ruby. Things I definitely wanted to know about because they made my tmp test folder not removed and affected subsequent specs in hard to debug ways. For these issues, `FileUtils.rm_rf` raising an error and not swallowing it would've helped, I didn't need any further retry/sleep/chmod manipulations, and they would have not helped my use case (because they would have not made any difference). By the way, I believe `FileUtils.rm_rf` on Windows seems to already have some of this chmod+retry behaviour @mame was mentioning: https://github.com/ruby/fileutils/blob/636975a184f07ccef31a0ffd9412be8fbb75…. I don't need nor like this behavior, but just mentioning it. In any case, I decided to stick to using `FileUtils.rm_r` and make sure I don't pass folders that don't exist as targets. That already has the exact behavior I'm asking for, so I'm fine with this issue being closed. ---------------------------------------- Feature #18784: `FileUtils.rm_f` and `FileUtils.rm_rf` should not mask exceptions https://bugs.ruby-lang.org/issues/18784#change-112511 * Author: deivid (David Rodríguez) * Status: Open ---------------------------------------- In recent times, I've been having issues with these methods because they don't let you know when some issue happened while trying to remove the given folders/files. IMO most users expect all pre-existing folders/files that are passed to these methods to be actually removed by the methods. Instead, when this happens, errors are silently swallowed and normally the result is that you will get some other issue further down the road, making the problem hard to debug. The current workaround I'm using is to double check whether the files still exist after the method, and raise a custom error if they do, but I still can't see the original problem, so issues are similarly hard to debug. This is also a deviation from how `rm -rf` and `rm -f` work, since these tools finish with a failure exit code when they fail to remove the given files. Given that `fileutils` is intended to mimic shell functionality, I think this is just a bug. I think the intention of the `force` flag here is to: * Don't prompt for confirmation. * Ignore given arguments that are not files that already exist. But any issue other than that should not be swallowed, and in general I think the method should succeed if and only if the given list of file names does not exist after the methods are done. I think this is in line with the following note I get when I run `man rm`, but also suggests that this is not the standard behavior of "historical implementations" > COMPATIBILITY > > The rm utility differs from historical implementations in that the -f option only masks attempts to remove non-existent files instead of masking a large variety of errors. I implemented this at https://github.com/ruby/fileutils/pull/58, but treating this as a bug. I can also implement a more conservative for approach for users that might be using `FileUtils.rm_rf` or `FileUtils.rm_f` but don't really care if the files are removed or not. Alternative proposals would be `FileUtils.rm_rf(force: strict)`, or `FileUtils.strict_rm_rf`, but to be honest, if this is considered a breaking change, I would ship it as a new major version, and let users update their code to swallow errors themselves if they need to. Happy to hear any feedback! -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121475] [Ruby Bug#21205] File::Stat#birthtime is available on Linux
by BertramScharpf (Bertram Scharpf) 31 Mar '25

31 Mar '25

Issue #21205 has been reported by BertramScharpf (Bertram Scharpf). ---------------------------------------- Bug #21205: File::Stat#birthtime is available on Linux https://bugs.ruby-lang.org/issues/21205 * Author: BertramScharpf (Bertram Scharpf) * Status: Open * ruby -v: ruby 3.3.7 (2025-01-15 revision be31f993d7) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Not that I would run into any problem with it, but this behaviour is confusing: RbConfig::CONFIG["platform"] #=> "amd64-freebsd14" (File.birthtime "/").class #=> Time (File.stat "/").birthtime.class #=> Time RbConfig::CONFIG["platform"] #=> "x86_64-linux" (File.birthtime "/").class #=> Time (File.stat "/").birthtime # raises NotImplementedError -- https://bugs.ruby-lang.org/

2 3