Bug #22539
closedClass#new shouldn't call refined initialize methods
Description
Since the introduction of opt_new in [Feature #21254], if a class's initialize method is refined, the refined version is called.
That's not the case when disabling compiler optimizations, or calling new with send.
After putting in on the dev meeting agenda [Misc #22417], it has been decided that new shouldn't call refined initialize.
Updated by byroot (Jean Boussier) about 7 hours ago
- Related to Feature #21254: Inlining Class#new added
Updated by byroot (Jean Boussier) about 7 hours ago
- Related to Feature #22501: Optimize `Hash.new` and `String.new` in `opt_new` added
Updated by Eregon (Benoit Daloze) about 7 hours ago
- Description updated (diff)
Updated by Eregon (Benoit Daloze) about 7 hours ago
- Status changed from Open to Closed
Applied in changeset git|db22451d7e1fcb04f033436fe099b0f0489d70d6.
[Bug #22539] Do not apply refinements to the initialize call of opt_new
opt_new inlines the call to initialize in the caller's bytecode, which made
refinements of #initialize active at the call site of .new apply, unlike
Class#new (e.g. via #send) and Ruby <= 3.4.
Add the internal VM_CALL_IGNORE_REFINEMENTS call flag, set it on the
initialize send emitted for opt_new, and skip the caller's crefs in
search_refined_method when it is set.
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com