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

[ruby-core:121372] [Ruby Bug#21185] Range#overlap? is not commutative with doubly-unbounded range argument.
by jeromepl (Jerome Parent-Levesque) 15 Mar '25

15 Mar '25

Issue #21185 has been reported by jeromepl (Jerome Parent-Levesque). ---------------------------------------- Bug #21185: Range#overlap? is not commutative with doubly-unbounded range argument. https://bugs.ruby-lang.org/issues/21185 * Author: jeromepl (Jerome Parent-Levesque) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In https://bugs.ruby-lang.org/issues/20725 the following: ``` ruby (nil..nil).overlap?(..3) ``` was fixed to output `true` instead of `false`. However, when reversing the order of the arguments the output is wrong: ``` ruby (..3).overlap?(nil..nil) # => Outputs `false` but should be `true` ``` I would like to attempt to fix this bug and will take a look at it this weekend. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:121076] [Ruby master Bug#21142] Lazy enumerator `.each_with_index` ignores `.take(0)` before it
by aaronkison (Aaron Kison) 14 Mar '25

14 Mar '25

Issue #21142 has been reported by aaronkison (Aaron Kison). ---------------------------------------- Bug #21142: Lazy enumerator `.each_with_index` ignores `.take(0)` before it https://bugs.ruby-lang.org/issues/21142 * Author: aaronkison (Aaron Kison) * Status: Open * ruby -v: 3.2.7 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Minimum code to produce problem: ``` class Numbers; def each; 100.times { yield _1 }; end; include Enumerable; end Numbers.new.lazy.take(0).each_with_index.map { _1 }.to_a ``` Output (at ruby 3.2.7, and 3.3.0): ``` [0, 1, ..., 99] ``` Expected output (and was as at ruby 3.1.4): ``` [] ``` It works when it opposite ordering: `Numbers.new.lazy.each_with_index.take(0).map { _1 }.to_a`. I suspect it may be related to the change here https://github.com/ruby/ruby/pull/11868/files but I'm not familiar with any of that code. It seems like it replaces an allocated index with a counting index, which my hunch is it works for every value except for 0. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:121359] [Ruby Feature#17016] Enumerable#accumulate
by midnight (Sarun R) 13 Mar '25

13 Mar '25

Issue #17016 has been updated by midnight (Sarun R). I have an issue that is kinda solvable with `scan` today and discover this old thread. Thank you all for putting thoughts into this. `enum_for` is really interesting, but it only works on `lazy` enumerable. Even though this issue is still pending, `each_with_object` seems available now. ~~~Ruby (1..10).each_with_object({ a: 0 }).map do |size, memo| memo[:a] += size end ~~~ This works on `lazy` too. From the observation, this was not the case back when the discussion started. ~~~Ruby (1..10).lazy.each_with_object({ a: 0 }).map do |size, memo| memo[:a] += size end ~~~ For anyone looking for something available today, `each_with_object` could be the solution. ---------------------------------------- Feature #17016: Enumerable#accumulate https://bugs.ruby-lang.org/issues/17016#change-112330 * Author: parker (Parker Finch) * Status: Open ---------------------------------------- ## Proposal UPDATE: Changed proposed method name from `#scan_left` to `#accumulate`. Add an `#accumulate` method to `Enumerable`. ## Background `#accumulate` is similar to `#inject`, but it accumulates the partial results that are computed. As a comparison: ``` [1, 2, 3].inject(0, &:+) => 6 [1, 2, 3].accumulate(0, &:+) => [0, 1, 3, 6] ``` Notably, the `accumulate` operation can be done lazily since it doesn't require processing the entire collection before computing a value. I recently described `#accumulate`, and its relationship to `#inject`, more thoroughly in [this blog post](https://medium.com/building-panorama-education/scan-left-a-lazy-incre…. ## Reasoning We heavily rely on the accumulate operation. We use an [event-sourcing](https://martinfowler.com/eaaDev/EventSourcing.html) pattern, which means that we are scanning over individual "events" and building up the corresponding state. We rely on the history of states and need to do this lazily (we stream events because they cannot fit in memory). Thus the scan operation is much more applicable than the inject operation. We suspect that there are many applications that could leverage the scan operation. [This question](https://stackoverflow.com/questions/1475808/cumulative-array-sum-… would be more easily answered by `#accumulate`. It is a natural fit for any application that needs to store the incrementally-computed values of an `#inject`, and a requirement for an application that needs to use `#inject` while maintaining laziness. ## Implementation There is a Ruby implementation of this functionality [here](https://github.com/panorama-ed/scan_left/) and an implementation in C [here](https://github.com/ruby/ruby/pull/3078). Update: @nobu has provided an alternative implementation [here](https://github.com/ruby/ruby/pull/1972). ## Counterarguments Introducing a new public method is committing to maintenance going forward and expands the size of the Ruby codebase -- it should not be done lightly. I think that providing the functionality here is worth the tradeoff, but I understand any hesitation to add yet more to Ruby! ---Files-------------------------------- scan_left_example.rb (2.93 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121077] [Ruby master Misc#21143] Speficy order of execution const_added vs inherited
by fxn (Xavier Noria) 13 Mar '25

13 Mar '25

Issue #21143 has been reported by fxn (Xavier Noria). ---------------------------------------- Misc #21143: Speficy order of execution const_added vs inherited https://bugs.ruby-lang.org/issues/21143 * Author: fxn (Xavier Noria) * Status: Open ---------------------------------------- The hooks `const_added` and `inherited` may need to be executed "together". For example, consider: ```ruby module M def self.const_added(cname) = ... class C def self.inherited(subclass) = ... end class D < C; end ``` When `D` is defined, two hooks are set to run, but in which order? Both orders make sense in a way: 1. When `inherited` is called, you can observe that the subclass has a permanent name, ergo it was assigned to a constant, which must me stored in a module. Therefore, the constant was added to said module module before `inherited` was invoked. 1. When `const_added` is called, you can `const_get` the symbol and observe the object is a class, hence with a superclass, hence inheritance already happened. The patch in https://github.com/ruby/ruby/pull/12759 documents and adds a test for (1). Rationale: 1. I believe it would be nice specify this order. 1. Chose (1) because it is how it works today. While the motivation for the patch was formal (to remove an ambiguity), after reflecting about this I realized users of Zeitwerk may depend on this. Zeitwerk uses `const_added` to set autoloads for child constants in namespaces. Thanks to the current order, code can be used in `inherited` hooks normally (it would not be ready if the order was different). -- https://bugs.ruby-lang.org/

5 14

[ruby-core:120459] [Ruby master Bug#20996] Embed Failure
by cfis (Charlie Savage) 13 Mar '25

13 Mar '25

Issue #20996 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #20996: Embed Failure https://bugs.ruby-lang.org/issues/20996 * Author: cfis (Charlie Savage) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Rice embeds Ruby in order to run its tests. This code has worked across multiple Ruby versions (current tests are 3.1, 3.2, 3.3 and 3.4 but previously tests were run on 3.0 and 2.x). However, it fails on 3.4 in different ways on different operating systems. The code is here - https://github.com/ruby-rice/rice/blob/master/test/embed_ruby.cpp#L10. ``` c int argc = 0; char* argv = nullptr; char** pArgv = &argv; // ruby_sysinit(&argc, &pArgv); ruby_init(); ruby_init_loadpath(); #if RUBY_API_VERSION_MAJOR == 3 && RUBY_API_VERSION_MINOR >= 1 // Force the prelude / builtins const char* opts[] = { "ruby", "-e;" }; ruby_options(2, (char**)opts); #endif ``` The test suite is here: https://github.com/ruby-rice/rice/actions/runs/12534403540/job/35007888873 With Ruby 3.4 on Fedora this fails with the following stack trace: ```c libruby.so.3.4!str_gsub(int argc, VALUE * argv, VALUE str, int bang) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\string.c:6348) libruby.so.3.4!vm_call_cfunc_with_frame_(rb_execution_context_t * ec, rb_control_frame_t * reg_cfp, struct rb_calling_info * calling, int argc, VALUE * argv, VALUE * stack_bottom) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm_insnhelper.c:3801) libruby.so.3.4!vm_call_cfunc_with_frame(rb_execution_context_t * ec, rb_control_frame_t * reg_cfp, struct rb_calling_info * calling) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm_insnhelper.c:3847) libruby.so.3.4!vm_sendish(struct rb_execution_context_struct * ec, struct rb_control_frame_struct * reg_cfp, struct rb_call_data * cd, VALUE block_handler) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm_callinfo.h:415) libruby.so.3.4!vm_exec_core(rb_execution_context_t * ec, rb_execution_context_t * ec@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\insns.def:851) libruby.so.3.4!vm_exec_loop(enum ruby_tag_type state, VALUE result) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm.c:2622) libruby.so.3.4!rb_vm_exec(rb_execution_context_t * ec) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm.c:2598) libruby.so.3.4!vm_yield_with_cref(int is_lambda, rb_execution_context_t * ec, int argc, const VALUE * argv, int kw_splat, const rb_cref_t * cref) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm.c:1670) libruby.so.3.4!vm_yield(rb_execution_context_t * ec, int argc, const VALUE * argv, int kw_splat) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm.c:1684) libruby.so.3.4!rb_yield_0(int argc, const VALUE * argv) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm_eval.c:1344) libruby.so.3.4!rb_yield(VALUE val) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm_eval.c:1360) libruby.so.3.4!each_value_i(VALUE key, VALUE value, VALUE _) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\hash.c:3015) libruby.so.3.4!hash_foreach_iter(st_data_t key, st_data_t key@entry, st_data_t value, st_data_t argp, st_data_t argp@entry, int error, int error@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\hash.c:1316) libruby.so.3.4!st_general_foreach(st_table * tab, st_table * tab@entry, st_foreach_check_callback_func * func, st_data_t arg) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\st.c:1543) libruby.so.3.4!rb_st_foreach_check(st_table * tab, st_table * tab@entry, st_foreach_check_callback_func * func, st_foreach_check_callback_func * func@entry, st_data_t arg, st_data_t arg@entry, st_data_t never, st_data_t never@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\st.c:1648) libruby.so.3.4!hash_foreach_call(VALUE arg, VALUE arg@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\hash.c:1439) libruby.so.3.4!rb_ensure(VALUE (*)(VALUE) b_proc, VALUE (*)(VALUE) b_proc@entry, VALUE data1, VALUE data1@entry, VALUE (*)(VALUE) e_proc, VALUE (*)(VALUE) e_proc@entry, VALUE data2, VALUE data2@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\eval.c:1074) libruby.so.3.4!rb_hash_foreach(VALUE hash, VALUE hash@entry, rb_foreach_func * func, rb_foreach_func * func@entry, VALUE farg, VALUE farg@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\hash.c:1463) libruby.so.3.4!rb_hash_each_value(VALUE hash) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\hash.c:3047) libruby.so.3.4!vm_call_cfunc_with_frame_(rb_execution_context_t * ec, rb_control_frame_t * reg_cfp, struct rb_calling_info * calling, int argc, VALUE * argv, VALUE * stack_bottom) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm_insnhelper.c:3801) libruby.so.3.4!vm_sendish(struct rb_execution_context_struct * ec, struct rb_control_frame_struct * reg_cfp, struct rb_call_data * cd, VALUE block_handler) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm_callinfo.h:415) libruby.so.3.4!vm_exec_core(rb_execution_context_t * ec, rb_execution_context_t * ec@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\insns.def:851) libruby.so.3.4!vm_exec_loop(enum ruby_tag_type state, VALUE result) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm.c:2622) libruby.so.3.4!rb_vm_exec(rb_execution_context_t * ec) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm.c:2598) libruby.so.3.4!rb_iseq_eval(const rb_iseq_t * iseq, const rb_iseq_t * iseq@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm.c:2850) libruby.so.3.4!load_iseq_eval(rb_execution_context_t * ec, VALUE fname) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\load.c:789) libruby.so.3.4!require_internal(rb_execution_context_t * ec, rb_execution_context_t * ec@entry, VALUE fname, VALUE fname@entry, int exception, int exception@entry, _Bool warn) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\load.c:1296) libruby.so.3.4!rb_require_string_internal(VALUE fname) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\load.c:1402) libruby.so.3.4!rb_require_string(VALUE fname) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\load.c:1388) libruby.so.3.4!vm_call_cfunc_with_frame_(rb_execution_context_t * ec, rb_control_frame_t * reg_cfp, struct rb_calling_info * calling, int argc, VALUE * argv, VALUE * stack_bottom) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm_insnhelper.c:3801) libruby.so.3.4!vm_call_cfunc_with_frame(rb_execution_context_t * ec, rb_control_frame_t * reg_cfp, struct rb_calling_info * calling) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm_insnhelper.c:3847) libruby.so.3.4!vm_sendish() (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm_callinfo.h:415) libruby.so.3.4!vm_exec_core(rb_execution_context_t * ec, rb_execution_context_t * ec@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\insns.def:898) libruby.so.3.4!vm_exec_loop(enum ruby_tag_type state, VALUE result) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm.c:2622) libruby.so.3.4!rb_vm_exec(rb_execution_context_t * ec) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm.c:2598) libruby.so.3.4!rb_iseq_eval(const rb_iseq_t * iseq, const rb_iseq_t * iseq@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm.c:2850) libruby.so.3.4!load_iseq_eval(rb_execution_context_t * ec, VALUE fname) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\load.c:789) libruby.so.3.4!require_internal(rb_execution_context_t * ec, rb_execution_context_t * ec@entry, VALUE fname, VALUE fname@entry, int exception, int exception@entry, _Bool warn) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\load.c:1296) libruby.so.3.4!rb_require_string_internal(VALUE fname) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\load.c:1402) libruby.so.3.4!rb_require_string(VALUE fname) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\load.c:1388) libruby.so.3.4!vm_call_cfunc_with_frame_(rb_execution_context_t * ec, rb_control_frame_t * reg_cfp, struct rb_calling_info * calling, int argc, VALUE * argv, VALUE * stack_bottom) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm_insnhelper.c:3801) libruby.so.3.4!vm_sendish() (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm_callinfo.h:415) libruby.so.3.4!vm_exec_core(rb_execution_context_t * ec, rb_execution_context_t * ec@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\insns.def:898) libruby.so.3.4!vm_exec_loop(enum ruby_tag_type state, VALUE result) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm.c:2622) libruby.so.3.4!rb_vm_exec(rb_execution_context_t * ec) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\vm.c:2598) libruby.so.3.4!ruby_init_prelude() (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\ruby.c:1750) libruby.so.3.4!ruby_opt_init(ruby_cmdline_options_t * opt) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\ruby.c:1811) libruby.so.3.4!ruby_opt_init(ruby_cmdline_options_t * opt) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\ruby.c:1767) libruby.so.3.4!prism_script(ruby_cmdline_options_t * opt, pm_parse_result_t * result) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\ruby.c:2199) libruby.so.3.4!process_options(int argc, int argc@entry, char ** argv, char ** argv@entry, ruby_cmdline_options_t * opt, ruby_cmdline_options_t * opt@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\ruby.c:2538) libruby.so.3.4!ruby_process_options(int argc, int argc@entry, char ** argv, char ** argv@entry) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\ruby.c:228) libruby.so.3.4!ruby_options(int argc, char ** argv) (\home\cfis\.rbenv\sources\3.4.1\ruby-3.4.1\eval.c:117) embed_ruby() (\usr\local\src\rice\test\embed_ruby.cpp:21) fixture__Keep_Alive__setup() (\usr\local\src\rice\test\test_Keep_Alive.cpp:60) Test_Suite::run(class Test_Suite * const this, class Test_Suite * const this@entry, class Test_Result & result) (\usr\local\src\rice\test\unittest.cpp:61) main(int argc, char ** argv) (\usr\local\src\rice\test\unittest.cpp:124) ``` On MacOS, it fails like this (see https://github.com/ruby-rice/rice/actions/runs/12534403540/job/35007888873) ```c -- C level backtrace information ------------------------------------------- /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_vm_bugreport+0xb6c) [0x103b1f10c] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_bug_for_fatal_signal+0x100) [0x103957970] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(sigsegv+0x84) [0x103a809d4] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x19a576584] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(callable_method_entry_or_negative+0xc0) [0x103afbac8] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_vm_search_method_slowpath+0xc8) [0x103aeefa4] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(gccct_method_search_slowpath+0x24) [0x103b0a484] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_funcallv_scope+0x17c) [0x103b002e0] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_funcall+0x88) [0x103b00750] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_obj_as_string+0x44) [0x103a927d4] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(ruby__sfvextra+0xe0) [0x103a8692c] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(BSD_vfprintf+0x60c) [0x103a84a24] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(ruby_vsprintf0+0xa8) [0x103a84100] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_sprintf+0x5c) [0x103a84278] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(unexpected_type+0x64) [0x103c63c64] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_unexpected_type+0x30) [0x103c63cac] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_fstring+0x1a0) [0x103a8f77c] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(require_internal+0x550) [0x1039c37f8] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_require_string_internal+0x58) [0x1039c2b6c] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_f_require+0x44) [0x1039c2a3c] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(vm_call_cfunc_with_frame_+0xf0) [0x103b10ce8] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(vm_exec_core+0x2468) [0x103af4cf0] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_vm_exec+0x1e8) [0x103af136c] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(load_iseq_eval+0x22c) [0x1039c56ac] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(require_internal+0x354) [0x1039c35fc] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_require_string_internal+0x58) [0x1039c2b6c] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_f_require+0x44) [0x1039c2a3c] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(vm_call_cfunc_with_frame_+0xf0) [0x103b10ce8] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(vm_exec_core+0x2468) [0x103af4cf0] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(rb_vm_exec+0x1e8) [0x103af136c] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(ruby_opt_init+0x138) [0x103a76fb4] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(ruby_process_options+0x1150) [0x103a75a90] /Users/runner/hostedtoolcache/Ruby/3.4.1/arm64/lib/libruby.3.4.dylib(ruby_options+0x9c) [0x1039621d8] /Users/runner/work/rice/rice/test/unittest(_Z10embed_rubyv+0x6c) [0x100fe3ba0] /Users/runner/work/rice/rice/test/unittest(_ZL42fixture__Address_Registration_Guard__setupv) [0x100fec360] /Users/runner/work/rice/rice/test/unittest(_ZN10Test_Suite3runER11Test_Result) [0x10190adf8] /Users/runner/work/rice/rice/test/unittest(main) [0x10190b748] ``` On Window, both MSVC and UCRT64 fails with a stack overflow error. MSVC: ```C x64-vcruntime140-ruby340.dll!ec_stack_overflow(rb_execution_context_struct * ec, int setup) Line 70 C x64-vcruntime140-ruby340.dll!rb_ec_stack_overflow(rb_execution_context_struct * ec, int crit) Line 96 C [Inline Frame] x64-vcruntime140-ruby340.dll!stack_check(rb_execution_context_struct *) Line 384 C x64-vcruntime140-ruby340.dll!rb_call0(rb_execution_context_struct * ec, unsigned __int64 recv, unsigned __int64 mid, int argc, const unsigned __int64 * argv, call_type call_scope, unsigned __int64 self) Line 553 C [Inline Frame] x64-vcruntime140-ruby340.dll!rb_call(unsigned __int64) Line 873 C x64-vcruntime140-ruby340.dll!rb_funcallv_kw(unsigned __int64 recv, unsigned __int64 mid, int argc, const unsigned __int64 * argv, int kw_splat) Line 1071 C x64-vcruntime140-ruby340.dll!rb_obj_call_init_kw(unsigned __int64 obj, int argc, const unsigned __int64 * argv, int kw_splat) Line 1753 C x64-vcruntime140-ruby340.dll!rb_class_new_instance_kw(int argc, const unsigned __int64 * argv, unsigned __int64 klass, int kw_splat) Line 2194 C x64-vcruntime140-ruby340.dll!rb_exc_new_str(unsigned __int64 etype, unsigned __int64 str) Line 1486 C x64-vcruntime140-ruby340.dll!rb_vm_register_special_exception_str(ruby_special_exceptions sp, unsigned __int64 cls, unsigned __int64 mesg) Line 3058 C x64-vcruntime140-ruby340.dll!Init_eval() Line 2163 C x64-vcruntime140-ruby340.dll!rb_call_inits() Line 37 C x64-vcruntime140-ruby340.dll!ruby_setup() Line 87 C x64-vcruntime140-ruby340.dll!ruby_init() Line 99 C unittest.exe!embed_ruby() Line 15 C++ unittest.exe!fixture__Keep_Alive__setup() Line 60 C++ unittest.exe!Test_Suite::run(Test_Result & result) Line 61 C++ unittest.exe!main(int argc, char * * argv) Line 124 C++ [External Code] ``` Mingw64 with UCRT64: ``` rb_ec_stack_overflow vm_insnhelper.c:96 stack_check vm_eval.c:384 stack_check vm_eval.c:379 rb_call0 vm_eval.c:553 rb_call vm_eval.c:873 rb_funcallv_kw vm_eval.c:1070 rb_obj_call_init_kw eval.c:1752 rb_class_new_instance_kw object.c:2191 rb_class_new_instance object.c:2199 rb_exc_new_str error.c:1485 rb_vm_register_special_exception_str vm.c:3057 Init_eval eval.c:2162 rb_call_inits inits.c:36 ruby_setup eval.c:86 <unknown> 0x0000000000000000 ``` What is the recommended way to embed Ruby 3.4 in a C program? -- https://bugs.ruby-lang.org/

3 5

[ruby-core:121354] [Ruby master Bug#21184] SyntaxError when combining `in` with inline hash-rocket (`=>`)
by jtannas (Joel Tannas) 13 Mar '25

13 Mar '25

Issue #21184 has been reported by jtannas (Joel Tannas). ---------------------------------------- Bug #21184: SyntaxError when combining `in` with inline hash-rocket (`=>`) https://bugs.ruby-lang.org/issues/21184 * Author: jtannas (Joel Tannas) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I believe the following should be valid syntax but it's throwing a `SyntaxError`: ``` ruby { a: 1 } in { a: 1 } # => true { a: 1 } in { a: Integer } # => true pattern = { "a" => 1 }; { "a" => 1 } in pattern # => true { "a" => 1 } in { "a" => 1 } # => SYNTAX ERROR ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117188] [Ruby master Bug#20340] Ractor comments not applying to constant targets
by kddnewton (Kevin Newton) 13 Mar '25

13 Mar '25

Issue #20340 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20340: Ractor comments not applying to constant targets https://bugs.ruby-lang.org/issues/20340 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In this example: ```ruby C, = { foo: bar } ``` You get: ``` == disasm: #<ISeq:<main>@test.rb:1 (1,0)-(1,17)> 0000 putobject :foo ( 1)[Li] 0002 putself 0003 opt_send_without_block <calldata!mid:bar, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0005 newhash 2 0007 dup 0008 expandarray 1, 0 0011 putspecialobject 3 0013 setconstant :C 0015 leave ``` But there's no difference from: ```ruby # shareable_constant_value: literal C, = { foo: bar } ``` I would have expected: ``` == disasm: #<ISeq:<main>@test.rb:1 (1,0)-(2,16)> 0000 putobject RubyVM::FrozenCore ( 2)[Li] 0002 putobject :foo 0004 putobject RubyVM::FrozenCore 0006 putself 0007 opt_send_without_block <calldata!mid:bar, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0009 putobject "C" 0011 opt_send_without_block <calldata!mid:ensure_shareable, argc:2, ARGS_SIMPLE> 0013 newhash 2 0015 opt_send_without_block <calldata!mid:make_shareable, argc:1, ARGS_SIMPLE> 0017 dup 0018 expandarray 1, 0 0021 putspecialobject 3 0023 setconstant :C 0025 leave ``` Is this omission intentional? For context, I'm building this in prism and I need to know if I should explicitly disable this behavior. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120611] [Ruby master Bug#21026] `def __FILE__.a; end` should be a syntax error
by Earlopain (Earlopain _) 13 Mar '25

13 Mar '25

Issue #21026 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21026: `def __FILE__.a; end` should be a syntax error https://bugs.ruby-lang.org/issues/21026 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Constants like `__FILE__`, `__LINE__` and `__ENCODING__` are literals and as such you shouldn't be able to defined singleton methods on them. It already doesn't seem to actually do anything: ```rb def __FILE__.a end __FILE__.a #=> undefined method 'a' for an instance of String (NoMethodError) ``` Wrapping it in brackets correctly reports a syntax error: ```rb code.rb:1: syntax error found (SyntaxError) > 1 | def (__FILE__).a | ^~~~~~~~ cannot define singleton method for literals 2 | end ``` The behavior is consistent between prism and parse.y `__ENCODING__` is frozen and so will result in a runtime error. Same for `__LINE__`, and also `__FILE__` with frozen string literals. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:120548] [Ruby master Bug#21016] What should massign with `shareable_constant_value: experimental_everything` freeze?
by nobu (Nobuyoshi Nakada) 13 Mar '25

13 Mar '25

Issue #21016 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21016: What should massign with `shareable_constant_value: experimental_everything` freeze? https://bugs.ruby-lang.org/issues/21016 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Derived from #21010. Even with prism: ```ruby # shareable_constant_value: experimental_everything A, = "" p A.frozen? #=> false ``` This `A` should be frozen? Furthermore: ```ruby # shareable_constant_value: experimental_everything A, a = "A", "a" p A.frozen? #=> false p a.frozen? #=> false ``` Should only `A` be frozen but not `a`? Or massign including a constant can freeze everything? -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120985] [Ruby master Misc#21134] DevMeeting-2025-03-13
by mame (Yusuke Endoh) 13 Mar '25

13 Mar '25

Issue #21134 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21134: DevMeeting-2025-03-13 https://bugs.ruby-lang.org/issues/21134 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/03/13 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/03/10. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

3 3