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

[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

[ruby-core:121477] [Ruby Bug#17506] Ractor isolation broken by ThreadGroup
by byroot (Jean Boussier) 30 Mar '25

30 Mar '25

Issue #17506 has been updated by byroot (Jean Boussier). Assignee set to ractor Retested on 3.4.2, and it seems the bug is still present. ---------------------------------------- Bug #17506: Ractor isolation broken by ThreadGroup https://bugs.ruby-lang.org/issues/17506#change-112495 * Author: marcandre (Marc-Andre Lafortune) * Status: Open * Assignee: ractor * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin18] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Ractors currently share the ThreadGroup. This doesn't seem very useful as there is no possible communication between the Threads of different Ractors. It is also an isolation error: ```ruby ThreadGroup.attr_accessor :foo var = Thread.current.group.foo = [:example] Ractor.new { Thread.current.group.foo << [:oops] }.take var # => [:example, [:oops]] ``` Should `Ractor.new` create a new `ThreadGroup`? Should `ThreadGroup` not have (non-shareable) instance variables? Or should `Ractor.new { Thread.current.group }.take` be `nil`? See also https://bugs.ruby-lang.org/issues/17505 about `nil`. Note that `Ractor` respects the `ThreadGroup`'s state: ```ruby Thread.current.group.enclose Ractor.new { Thread.current.group.add(Thread.current) }.take # => can't move to the enclosed thread group Thread.current.group.freeze Ractor.new {} # => ThreadError (can't start a new thread (frozen ThreadGroup)) ``` I am not sure what is the best behavior as I don't have enough experience with how ThreadGroups are used, especially enclosed ThreadGroups. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121428] [Ruby Bug#21195] Crash when using IO#timeout
by nickamorim (Nick Amorim) 30 Mar '25

30 Mar '25

Issue #21195 has been reported by nickamorim (Nick Amorim). ---------------------------------------- Bug #21195: Crash when using IO#timeout https://bugs.ruby-lang.org/issues/21195 * Author: nickamorim (Nick Amorim) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- We have adopted the [IO#timeout](https://bugs.ruby-lang.org/issues/18630) feature in Dalli ([ref](https://github.com/petergoldstein/dalli/pull/1025)) for I/O timeouts. We regularly see crashes in our CI environment that I was able to pinpoint to calling `IO#gets` with `IO#timeout`: ## C Backtrace ``` _bk;t=1742524358337-- Threading information --------------------------------------------------- _bk;t=1742524358337Total ractor count: 1 _bk;t=1742524358337Ruby thread count for this ractor: 10 _bk;t=1742524358337 _bk;t=1742524358337-- C level backtrace information ------------------------------------------- _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_print_backtrace+0x8) [0x798534ef70c2] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_dump.c:823 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_vm_bugreport) /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_dump.c:1155 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_bug_without_die_internal+0x6b) [0x798534bf99b1] /tmp/ruby-build/ruby-3.4.2-pshopify2/error.c:1097 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_bug) /tmp/ruby-build/ruby-3.4.2-pshopify2/error.c:1115 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_syserr_new_path_in+0x30) [0x798534bf9ea2] /tmp/ruby-build/ruby-3.4.2-pshopify2/error.c:3927 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_syserr_fail_path_in+0xf) [0x798534cd8daf] /tmp/ruby-build/ruby-3.4.2-pshopify2/error.c:3915 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(io_fillbuf+0x99) [0x798534d22679] /tmp/ruby-build/ruby-3.4.2-pshopify2/io.c:2642 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(appendline+0x3d) [0x798534d250d5] /tmp/ruby-build/ruby-3.4.2-pshopify2/io.c:3954 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_io_getline_0) /tmp/ruby-build/ruby-3.4.2-pshopify2/io.c:4215 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_io_getline_1+0x21) [0x798534d25edb] /tmp/ruby-build/ruby-3.4.2-pshopify2/io.c:4273 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_io_getline) /tmp/ruby-build/ruby-3.4.2-pshopify2/io.c:4293 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_io_gets_m) /tmp/ruby-build/ruby-3.4.2-pshopify2/io.c:4387 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_call_cfunc_with_frame_+0x11f) [0x798534ecd7af] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_insnhelper.c:3794 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_sendish+0xbb) [0x798534ed6e6c] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_insnhelper.c:5961 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_exec_core) /tmp/ruby-build/ruby-3.4.2-pshopify2/insns.def:898 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_vm_exec+0x189) [0x798534ede289] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm.c:2595 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_yield_values2+0x63) [0x798534ee2be3] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm.c:1676 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_ensure+0xe6) [0x798534ce1116] /tmp/ruby-build/ruby-3.4.2-pshopify2/eval.c:1074 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_call_cfunc_with_frame_+0x11f) [0x798534ecd7af] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_insnhelper.c:3794 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_sendish+0xd3) [0x798534ec6da3] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_insnhelper.c:5961 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_exec_core+0x1151) [0x798534ed7e71] /tmp/ruby-build/ruby-3.4.2-pshopify2/insns.def:851 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_vm_exec+0x189) [0x798534ede289] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm.c:2595 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_yield_with_cref+0x42) [0x798534ee3348] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm.c:1676 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_yield) /tmp/ruby-build/ruby-3.4.2-pshopify2/vm.c:1684 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_yield_0) /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_eval.c:1344 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_yield) /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_eval.c:1360 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_ary_collect+0x5c) [0x798534c1010c] /tmp/ruby-build/ruby-3.4.2-pshopify2/array.c:3645 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_call_cfunc_with_frame_+0x11f) [0x798534ecd7af] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_insnhelper.c:3794 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_sendish+0xd3) [0x798534ec6da3] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_insnhelper.c:5961 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_exec_core+0x1151) [0x798534ed7e71] /tmp/ruby-build/ruby-3.4.2-pshopify2/insns.def:851 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_vm_exec+0x189) [0x798534ede289] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm.c:2595 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_yield_with_cref+0x42) [0x798534ee3348] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm.c:1676 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_yield) /tmp/ruby-build/ruby-3.4.2-pshopify2/vm.c:1684 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_yield_0) /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_eval.c:1344 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_yield) /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_eval.c:1360 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(RB_FL_TEST_RAW+0x0) [0x798534c0951c] /tmp/ruby-build/ruby-3.4.2-pshopify2/array.c:2641 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(RB_FL_ANY_RAW) ./include/ruby/internal/fl_type.h:520 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_array_len) ./include/ruby/internal/core/rarray.h:259 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_ary_each) /tmp/ruby-build/ruby-3.4.2-pshopify2/array.c:2640 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_call_cfunc_with_frame_+0x11f) [0x798534ecd7af] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_insnhelper.c:3794 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_sendish+0xd3) [0x798534ec6da3] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm_insnhelper.c:5961 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_exec_core+0x1151) [0x798534ed7e71] /tmp/ruby-build/ruby-3.4.2-pshopify2/insns.def:851 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(vm_exec_loop+0xa) [0x798534ede529] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm.c:2622 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_vm_exec) /tmp/ruby-build/ruby-3.4.2-pshopify2/vm.c:2601 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_vm_invoke_proc+0x66) [0x798534edf276] /tmp/ruby-build/ruby-3.4.2-pshopify2/vm.c:1770 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_proc_call_kw+0x6a) [0x798534dc825a] /tmp/ruby-build/ruby-3.4.2-pshopify2/proc.c:988 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(exec_end_procs_chain+0x44) [0x798534ce25cd] /tmp/ruby-build/ruby-3.4.2-pshopify2/eval_jump.c:105 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_ec_exec_end_proc) /tmp/ruby-build/ruby-3.4.2-pshopify2/eval_jump.c:121 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_ec_teardown+0xcc) [0x798534ce27bc] /tmp/ruby-build/ruby-3.4.2-pshopify2/eval.c:155 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(rb_ec_cleanup+0x144) [0x798534ce29f4] /tmp/ruby-build/ruby-3.4.2-pshopify2/eval.c:207 _bk;t=1742524358649/usr/local/ruby/lib/libruby.so.3.4(ruby_run_node+0x8d) [0x798534ce2e1d] /tmp/ruby-build/ruby-3.4.2-pshopify2/eval.c:319 ``` ## Ruby Backtrace ``` _bk;t=1742524358337/tmp/bundle/ruby/3.4.0/bundler/gems/dalli-fbd3cba210d9/lib/dalli/protocol/connection_manager.rb:157: [BUG] rb_sys_fail_path_in(io_fillbuf, fd:16 ) - errno == 0 _bk;t=1742524358337ruby 3.4.2 (2025-03-18 revision 20130836d0) +PRISM [x86_64-linux] _bk;t=1742524358337 _bk;t=1742524358337-- Control frame information ----------------------------------------------- _bk;t=1742524358337c:0042 p:---- s:0206 e:000205 CFUNC :gets _bk;t=1742524358337c:0041 p:0007 s:0201 e:000200 METHOD /tmp/bundle/ruby/3.4.0/bundler/gems/dalli-fbd3cba210d9/lib/dalli/protocol/connection_manager.rb:157 _bk;t=1742524358337c:0040 p:0005 s:0195 e:000194 METHOD /tmp/bundle/ruby/3.4.0/bundler/gems/dalli-fbd3cba210d9/lib/dalli/protocol/meta/response_processor.rb:242 _bk;t=1742524358337c:0039 p:0003 s:0191 e:000190 METHOD /tmp/bundle/ruby/3.4.0/bundler/gems/dalli-fbd3cba210d9/lib/dalli/protocol/meta/response_processor.rb:246 _bk;t=1742524358337c:0038 p:0003 s:0186 e:000185 METHOD /tmp/bundle/ruby/3.4.0/bundler/gems/dalli-fbd3cba210d9/lib/dalli/protocol/meta/response_processor.rb:186 _bk;t=1742524358337c:0037 p:0007 s:0180 e:000179 METHOD /tmp/bundle/ruby/3.4.0/bundler/gems/dalli-fbd3cba210d9/lib/dalli/protocol/meta/response_processor.rb:108 _bk;t=1742524358337c:0036 p:0025 s:0176 e:000175 METHOD /tmp/bundle/ruby/3.4.0/bundler/gems/dalli-fbd3cba210d9/lib/dalli/protocol/meta.rb:232 _bk;t=1742524358337c:0035 p:0021 s:0171 e:000170 METHOD /tmp/bundle/ruby/3.4.0/bundler/gems/dalli-fbd3cba210d9/lib/dalli/protocol/base.rb:37 _bk;t=1742524358337c:0034 p:0010 s:0163 e:000162 BLOCK /tmp/bundle/ruby/3.4.0/bundler/gems/dalli-fbd3cba210d9/lib/dalli/options.rb:18 [FINISH] _bk;t=1742524358337c:0033 p:---- s:0160 e:000159 CFUNC :synchronize _bk;t=1742524358337c:0032 p:0006 s:0156 e:000155 METHOD /tmp/bundle/ruby/3.4.0/bundler/gems/dalli-fbd3cba210d9/lib/dalli/options.rb:17 _bk;t=1742524358337c:0031 p:0008 s:0150 e:000149 BLOCK /tmp/bundle/ruby/3.4.0/bundler/gems/dalli-fbd3cba210d9/lib/dalli/client.rb:324 [FINISH] _bk;t=1742524358337c:0030 p:---- s:0146 e:000145 CFUNC :map _bk;t=1742524358337c:0029 p:0011 s:0142 e:000141 METHOD /tmp/bundle/ruby/3.4.0/bundler/gems/dalli-fbd3cba210d9/lib/dalli/client.rb:324 ``` Unfortunately, I was not able to build a reproducible test. I have tried running on both Ruby 3.4.1 and 3.4.2 with no luck. The crash happens here: https://github.com/Shopify/ruby/blob/v3.4.1-pshopify3/io.c#L2632-L2643. Please let me know if there's any more information that I can provide :-) -- https://bugs.ruby-lang.org/

4 7

[ruby-core:120895] [Ruby master Bug#21117] Inconsistent behaviour between "_1" and "it" variables
by radarek 30 Mar '25

30 Mar '25

Issue #21117 has been reported by radarek (Radosław Bułat). ---------------------------------------- Bug #21117: Inconsistent behaviour between "_1" and "it" variables https://bugs.ruby-lang.org/issues/21117 * Author: radarek (Radosław Bułat) * 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 ---------------------------------------- I believe variables `_1` and `it` should have consistent behaviour and the same as normal local variables. Here are inconsistencies: ```ruby # 1. Assigning new value [1, 2, 3].each { |v| v = v + 1; p v } # works as expected [1, 2, 3].each { it = it + 1; p it } # works as expected [1, 2, 3].each { _1 = _1 + 1; p _1 } # SyntaxError # 2. Using operators like += on them [1, 2, 3].each { |v| v += 1; p v } # works as expected [1, 2, 3].each { it += 1; p it } # SyntaxError but I expected it to work correctly after 1st point [1, 2, 3].each { _1 += 1; p _1 } # works, which is inconsistent with 1 point # however, this one does not work [1, 2, 3].map { _1 += 1 } # runtime error is raised: undefined method '+' for nil (NoMethodError) ``` If both `_1` and `it` are advertised as block local variables then I would expect that overwriting works correctly, both using expressions like `_1 = _1 + 1` and `_1 *= 2`. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:120808] [Ruby master Bug#21094] Module#set_temporary_name does not affect a name of a nested module
by andrykonchin (Andrew Konchin) 29 Mar '25

29 Mar '25

Issue #21094 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21094: Module#set_temporary_name does not affect a name of a nested module https://bugs.ruby-lang.org/issues/21094 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Wondering whether it's intentional and correct behaviour: ```ruby m = Module.new m::N = Module.new p m::N.name # => "#<Module:0x000000010d0a00b0>::N" m.set_temporary_name("foo") p m::N.name # => "#<Module:0x000000010d0a00b0>::N" ``` I would expect that setting `foo` as a temporary name changes `m::N.name` to `foo::N`. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:121376] [Ruby Bug#21186] Inconsistent parsing of ?あand 0
by qnighy (Masaki Hara) 29 Mar '25

29 Mar '25

Issue #21186 has been reported by qnighy (Masaki Hara). ---------------------------------------- Bug #21186: Inconsistent parsing of ?あand 0 https://bugs.ruby-lang.org/issues/21186 * Author: qnighy (Masaki Hara) * Status: Open * ruby -v: ruby 3.5.0dev (2025-03-16T03:09:18Z master 06919949a6) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `?あand 0` has inconsistent behavior between Prism and parse.y. ```console % ./miniruby --parser=parse.y -e "?aand 0" -e:1: syntax error, unexpected '?' ?aand 0 ./miniruby: compile error (SyntaxError) % ./miniruby --parser=parse.y -e "?あand 0" % ./miniruby --parser=prism -e "?aand 0" -e: -e:1: syntax error found (SyntaxError) > 1 | ?aand 0 | ^ unexpected '?', ignoring it % ./miniruby --parser=prism -e "?あand 0" -e: -e:1: syntax error found (SyntaxError) > 1 | ?あand 0 | ^ unexpected '?', ignoring it ``` | |parse.y|Prism| |----------|-------|-----| |`?aand 0` | x | x | |`?あand 0`| | x | -- https://bugs.ruby-lang.org/

3 3

[ruby-core:114410] [Ruby master Bug#19841] Marshal.dump stack overflow with recursive Time
by segiddins (Samuel Giddins) 29 Mar '25

29 Mar '25

Issue #19841 has been reported by segiddins (Samuel Giddins). ---------------------------------------- Bug #19841: Marshal.dump stack overflow with recursive Time https://bugs.ruby-lang.org/issues/19841 * Author: segiddins (Samuel Giddins) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` ruby #!/usr/bin/env ruby puts RUBY_VERSION t = Time.at(0, 1, :nanosecond) t.instance_variable_set :@itself, t Marshal.dump(t) ``` Yields a stack overflow error from the `Marshal.dump` call, even though Marshal is explicitly able to handle cyclical references -- https://bugs.ruby-lang.org/

6 8

[ruby-core:121468] [Ruby Feature#17414] Ractor should allow access to shareable attributes for Modules/Classes
by jhawthorn (John Hawthorn) 28 Mar '25

28 Mar '25

Issue #17414 has been updated by jhawthorn (John Hawthorn). Status changed from Assigned to Closed I think we can close this as accessing the class instance variables has been allowed for a while (Ruby 3.1?) ``` ruby module Config class << self attr_accessor :conf end self.conf = 42 end Ractor.new { Config.conf = 66 }.take # => can not set instance variables of classes/modules by non-main Ractors (Ractor::IsolationError) Ractor.new { puts Config.conf }.take # => 42 ``` ---------------------------------------- Feature #17414: Ractor should allow access to shareable attributes for Modules/Classes https://bugs.ruby-lang.org/issues/17414#change-112475 * Author: marcandre (Marc-Andre Lafortune) * Status: Closed * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Current situation is *very* limiting. Use-case: global config. Example: [yaml has a global config](https://github.com/ruby/psych/blob/master/lib/psych.rb#L637-L640) and it's not clear to me how to make that Ractor-aware (nicely). It is possible to have the same effect but in ugly ways: ```ruby # Using instance variables of Module not allowed: module Config class << self attr_accessor :conf end self.conf = 42 end Ractor.new { Config.conf = 66 }.take # => can not access instance variables from non-main Ractors Ractor.new { puts Config.conf }.take # => can not access instance variables from non-main Ractors # Same functionality using constants allowed: module Config class << self def conf CONF end def conf=(new_conf) remove_const(:CONF) const_set(:CONF, new_conf) end end CONF = 42 end Ractor.new { Config.conf = 66 }.take # => ok Ractor.new { puts Config.conf }.take # => 66 # Same functionality using methods allowed: module Config class << self def conf 42 end def conf=(new_conf) singleton_class.undef_method(:conf) define_singleton_method(:conf, &Ractor.make_shareable(Proc.new { new_conf })) end end end Ractor.new { Config.conf = 66 }.take # => ok Ractor.new { puts Config.conf }.take # => 66 ``` The priority would be to allow reading these instance variables if they are shareable. Ideally writing would also be allowed, but limiting that to main ractor is less probablematic than with reading. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121448] [Ruby Bug#21199] Psych.dump and load on Date before 1582-10-15
by fitmap (Justin Peal) 28 Mar '25

28 Mar '25

Issue #21199 has been reported by fitmap (Justin Peal). ---------------------------------------- Bug #21199: Psych.dump and load on Date before 1582-10-15 https://bugs.ruby-lang.org/issues/21199 * Author: fitmap (Justin Peal) * Status: Open * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The code is: require 'date' require 'psych' date = Date.new(1582, 10, 4) p "date=#{date.inspect}" str = Psych.dump(date, permitted_classes: [Date]) p "str=#{str}" date2 = Psych.load(str, permitted_classes: [Date]) p "date2=#{date2.inspect}" The output is: "date=#<Date: 1582-10-04 ((2299160j,0s,0n),+0s,2299161j)>" "str=--- 1582-10-14\n" "date2=#<Date: 1582-10-14 ((2299160j,0s,0n),+0s,-Infj)>" -- https://bugs.ruby-lang.org/

3 3