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

[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

[ruby-core:121458] [Ruby Bug#21202] Ripper wrongly concats separate tstring_content within nested unterminated heredoc
by tompng (tomoya ishida) 27 Mar '25

27 Mar '25

Issue #21202 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21202: Ripper wrongly concats separate tstring_content within nested unterminated heredoc https://bugs.ruby-lang.org/issues/21202 * Author: tompng (tomoya ishida) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ruby code = <<~'CODE' <<H1 #{<<H2}a H2 b CODE Ripper.tokenize(code) #=> ["<<H1", "\n", "\#{", "<<H2", "}", "a\nb\n", "H2\n"] ~~~ `"a\nb\n"` should be a separate token `"a\n"` and `"b\n"` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:120979] [Ruby master Feature#21133] [ruby/logger] Add an option to disable writing the header when creating a new log file
by viralpraxis (Iaroslav Kurbatov) 27 Mar '25

27 Mar '25

Issue #21133 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Feature #21133: [ruby/logger] Add an option to disable writing the header when creating a new log file https://bugs.ruby-lang.org/issues/21133 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open ---------------------------------------- Creating a logger automatically writes a hardcoded header comment ("# Logfile created on ..."): https://github.com/ruby/logger/blob/0eb10f2d278435899ce9055c98eb5b53caa0092… As far as I can see, it helps to verify that logdev is writable as early as possible (rather than on the first log entry) and it also serves as a useful indicator of which program created the logfile. However, this header can introduce unnecessary complexity is some use-cases -- especially when working with third-party tools that need to ignore these lines. I think it might make sense to add a new configuration option (`skip_header`) which will be `false` by default so the changes are backward-compatible. Proposed implementation: https://github.com/ruby/logger/pull/119 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:121450] [Ruby Bug#21200] Ractor spuriously hangs, segfault or errors
by Eregon (Benoit Daloze) 27 Mar '25

27 Mar '25

Issue #21200 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21200: Ractor spuriously hangs, segfault or errors https://bugs.ruby-lang.org/issues/21200 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: ractor * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- For a new test `test_ractor_parallel` I added in https://github.com/ruby/etc/pull/52/files This seems a Ractor bug. Example failures: https://github.com/ruby/ruby/actions/runs/14097239052/job/39486770259?pr=12… ``` 1) Failure: TestEtc#test_ractor_parallel [/Users/runner/work/ruby/ruby/src/test/etc/test_etc.rb:178]: assert_separately failed with error message pid 51588 exit 0 | [BUG] ``` https://github.com/ruby/ruby/actions/runs/14094646363/job/39479353266?pr=12… ``` TestEtc#test_ractor_parallel [/Users/runner/work/ruby/ruby/src/test/etc/test_etc.rb:178]: assert_separately failed with error message pid 47346 exit 0 | [BUG] pthread_mutex_lock: Invalid argument (EINVAL) | ruby 3.5.0dev (2025-03-26T22:25:25Z pull/12984/merge 1ea32181b7) +PRISM [arm64-darwin23] | | -- Crash Report log information -------------------------------------------- | See Crash Report log file in one of the following locations: | * ~/Library/Logs/DiagnosticReports | * /Library/Logs/DiagnosticReports | for more details. | Don't forget to include the above Crash Report log file in bug reports. | | -- Control frame information ----------------------------------------------- | | | -- Threading information --------------------------------------------------- | Total ractor count: 1 | Ruby thread count for this ractor: 0 | | -- C level backtrace information ------------------------------------------- | [BUG] Segmentation fault at 0xfffffffffffffff8 | ruby 3.5.0dev (2025-03-26T22:25:25Z pull/12984/merge 1ea32181b7) +PRISM [arm64-darwin23] | | -- Crash Report log information -------------------------------------------- | See Crash Report log file in one of the following locations: | * ~/Library/Logs/DiagnosticReports | * /Library/Logs/DiagnosticReports | for more details. | Don't forget to include the above Crash Report log file in bug reports. | | Crashed while printing bug report | [IMPORTANT] | Don't forget to include the Crash Report log file under | DiagnosticReports directory in bug reports. | ``` https://github.com/ruby/ruby/actions/runs/14069270994/job/39402894235#step:… ``` 1) Error: TestEtc#test_ractor_parallel: Test::Unit::ProxyError: execution of Test::Unit::CoreAssertions#assert_separately expired timeout (10 sec) pid 145797 killed by SIGKILL (signal 9) | /home/runner/work/ruby/ruby/src/test/etc/test_etc.rb:178:in 'TestEtc#test_ractor_parallel' ``` The test has been disabled for now in https://github.com/ruby/ruby/pull/12992. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114147] [Ruby master Bug#19765] Ractor.make_shareable ignores self of a proc created from a Method
by Ethan (Ethan -) 27 Mar '25

27 Mar '25

Issue #19765 has been reported by Ethan (Ethan -). ---------------------------------------- Bug #19765: Ractor.make_shareable ignores self of a proc created from a Method https://bugs.ruby-lang.org/issues/19765 * Author: Ethan (Ethan -) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-07-12T00:26:03Z master dfe782be17) [x86_64-darwin21] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- An unshareable receiver of a Proc or a Method will cause make_shareable to error, but this does not happen with a proc from Method#to_proc: ```ruby str = "" a = str.instance_exec { proc { to_s } } Ractor.make_shareable a # => <internal:ractor>:820:in `make_shareable': Proc's self is not shareable: #<Proc:0x00000001064b62c8 (irb):1> (Ractor::IsolationError) b = str.instance_exec { method(:to_s) } Ractor.make_shareable b # => <internal:ractor>:820:in `make_shareable': can not make shareable object for #<Method: String#to_s()> (Ractor::Error) c = str.instance_exec { method(:to_s).to_proc } Ractor.make_shareable c c.call # => "" str[0] = "!" c.call # => "!" ``` Related, maybe: #19372 #19374 Tangential: why does Proc cause Ractor::IsolationError but Method causes Ractor::Error? -- https://bugs.ruby-lang.org/

3 2