May 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:113693] [Ruby master Feature#19698] Need an idiomatic way to define an empty range
by shouichi (Shouichi KAMIYA) 12 Jul '23

12 Jul '23

Issue #19698 has been reported by shouichi (Shouichi KAMIYA). ---------------------------------------- Feature #19698: Need an idiomatic way to define an empty range https://bugs.ruby-lang.org/issues/19698 * Author: shouichi (Shouichi KAMIYA) * Status: Open * Priority: Normal ---------------------------------------- It seems there is no idiomatic way to define an empty range. We can define empty ranges in several ways such as ``` ruby irb(main):001:0> (0...0).none? => true irb(main):002:0> (1...-1).none? => true ``` I think the above examples do not communicate the intention well. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112988] [Ruby master Bug#19544] Custom quotes inconsistency
by hurricup (Alexandr Evstigneev) 11 Jul '23

11 Jul '23

Issue #19544 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Bug #19544: Custom quotes inconsistency https://bugs.ruby-lang.org/issues/19544 * Author: hurricup (Alexandr Evstigneev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- According to `parse_percent` in `parse.y`: For `%` we should be able use ascii non alphanumeric delimiters. But, `p % jim beam ;` does not work. Presumably because of some look-ahead distincting `%` from percent-string starter. Seems it is the same for any `\s` after `%` For the explicit `%` construction, with type specifier `%[QqWwIisrx]` we should be able to use non-alphanumeric ascii characters, which includes `\s`. But: This works: ``` p %s jim beam ``` And this does not: ``` p %w jim\ beam ``` with unterminated list error. First seems unavoidable, but second looks like obvious error of finding terminating `\n` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:112773] [Ruby master Feature#19521] Support for `Module#name=` and `Class#name=`.
by ioquatix (Samuel Williams) 02 Jul '23

02 Jul '23

Issue #19521 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19521: Support for `Module#name=` and `Class#name=`. https://bugs.ruby-lang.org/issues/19521 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- See https://bugs.ruby-lang.org/issues/19450 for previous discussion and motivation. This proposal introduces `Class#name=` to set the temporary class name. This is an alternative or addition to <https://bugs.ruby-lang.org/issues/19520>. ```ruby c = Class.new do self.name = "fake name" end c = Class.new c.name = "fake name" ``` Alternatively, we could use `set_name`: ```ruby Class.new do set_name "fake_name" end ``` ## Example usage The current Ruby test suite has code which shows the usefulness of this new method: ```ruby def labeled_module(name, &block) Module.new do singleton_class.class_eval { define_method(:to_s) {name} alias inspect to_s alias name to_s } class_eval(&block) if block end end module_function :labeled_module def labeled_class(name, superclass = Object, &block) Class.new(superclass) do singleton_class.class_eval { define_method(:to_s) {name} alias inspect to_s alias name to_s } class_eval(&block) if block end end module_function :labeled_class ``` The updated code would look like this: ```ruby def labeled_module(name, &block) Module.new do self.name = name class_eval(&block) if block end end def labeled_class(name, superclass = Object, &block) Class.new(superclass) do self.name = name class_eval(&block) if block end end module_function :labeled_class ``` Because the name cannot be set as part of `.new`, we have to have a separate block to set the name, before calling `class_eval`. I think the ergonomics and performance of this are slightly worse than the [counter proposal](https://bugs.ruby-lang.org/issues/19520). -- https://bugs.ruby-lang.org/

10 30

[ruby-core:112871] [Ruby master Bug#19529] [BUG] ObjectSpace::WeakMap can segfault after compaction
by byroot (Jean Boussier) 25 Jun '23

25 Jun '23

Issue #19529 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #19529: [BUG] ObjectSpace::WeakMap can segfault after compaction https://bugs.ruby-lang.org/issues/19529 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * ruby -v: 3.2.1, 2.7.5p203 * Backport: 2.7: WONTFIX, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Reproduction script: ```ruby wm = ObjectSpace::WeakMap.new obj = Object.new 100.times do |i| GC.compact wm[i] = obj # [BUG] Segmentation fault at 0x0000000000000001 end ``` Crash report: ``` /tmp/weakmap.rb:5: [BUG] Segmentation fault at 0x0000000000000003 ruby 3.2.1 (2023-02-08 revision 31819e82c8) [arm64-darwin22] -- 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 ----------------------------------------------- c:0005 p:---- s:0023 e:000022 CFUNC :[]= c:0004 p:0016 s:0017 e:000015 BLOCK /tmp/weakmap.rb:5 [FINISH] c:0003 p:---- s:0012 e:000011 CFUNC :times c:0002 p:0017 s:0008 E:0025b0 EVAL /tmp/weakmap.rb:3 [FINISH] c:0001 p:0000 s:0003 E:0010b0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /tmp/weakmap.rb:3:in `<main>' /tmp/weakmap.rb:3:in `times' /tmp/weakmap.rb:5:in `block in <main>' /tmp/weakmap.rb:5:in `[]=' -- Machine register context ------------------------------------------------ x0: 0x000000016da8a6b0 x1: 0x000000016da8a6a8 x2: 0x000000000000003d x3: 0x0000000000000001 x4: 0x0000000000000000 x5: 0x0000000000000b00 x6: 0x0000600002db4b00 x7: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x000000016da8a6a8 x20: 0x000000000000003d x21: 0x0000000000000003 x22: 0x0000000000000001 x23: 0x00000001023df7b8 x24: 0x0000000000000001 x25: 0x0000000000000000 x26: 0x00006000027bdf80 x27: 0xffffffffffffffff x28: 0xffffffffffffffff lr: 0x0000000102ca28f0 fp: 0x000000016da8a680 sp: 0x000000016da8a640 -- C level backtrace information ------------------------------------------- /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_vm_bugreport+0x9a0) [0x102d3ba98] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_bug_for_fatal_signal+0x160) [0x102b5fe14] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(sig_do_nothing+0x0) [0x102c9a354] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x19b63c2a4] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_st_update+0x328) [0x102ca28f0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_st_update+0x328) [0x102ca28f0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(wmap_aset+0x90) [0x102b88e9c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_call_cfunc_with_frame+0xe8) [0x102d2fc7c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_sendish+0x4cc) [0x102d31fdc] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_exec_core+0x239c) [0x102d136c8] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_vm_exec+0xad4) [0x102d26bf0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(invoke_block_from_c_bh+0x398) [0x102d36438] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_yield_1+0x7c) [0x102d1f208] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(int_dotimes+0x148) [0x102bff3ec] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_call_cfunc_with_frame+0xe8) [0x102d2fc7c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_sendish+0x4cc) [0x102d31fdc] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_exec_core+0x2350) [0x102d1367c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_vm_exec+0xad4) [0x102d26bf0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_ec_exec_node+0x12c) [0x102b6b4ac] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(ruby_run_node+0x60) [0x102b6b318] /opt/rubies/3.2.1/bin/ruby(main+0x68) [0x102377f34] ``` Seems to happens since 2.7. -- https://bugs.ruby-lang.org/

6 11

[ruby-core:111735] [Ruby master Bug#19323] Integer overflow in `Integer#<<`
by nobu (Nobuyoshi Nakada) 25 Jun '23

25 Jun '23

Issue #19323 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19323: Integer overflow in `Integer#<<` https://bugs.ruby-lang.org/issues/19323 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- ```ruby require 'rbconfig/sizeof' char_bit = RbConfig::LIMITS["UCHAR_MAX"].bit_length size_max = RbConfig::LIMITS["SIZE_MAX"] size_bit_max = size_max * char_bit 1 << size_bit_max ``` The above code raises an "integer overflow" error. ``` -:5:in `<<': integer overflow: 4611686018427387905 * 4 > 18446744073709551615 (ArgumentError) from -:5:in `<main>' ``` It doesn't seem like a proper or intentional exception. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:112697] [Ruby master Bug#19479] Support IPv4-mapped IPv6 addresses in IPAddr#private?
by tgxworld (Guo Xiang Tan) 22 Jun '23

22 Jun '23

Issue #19479 has been reported by tgxworld (Guo Xiang Tan). ---------------------------------------- Bug #19479: Support IPv4-mapped IPv6 addresses in IPAddr#private? https://bugs.ruby-lang.org/issues/19479 * Author: tgxworld (Guo Xiang Tan) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` irb(main):010:0> IPAddr.new("172.16.0.0").private? => true irb(main):011:0> IPAddr.new("::ffff:172.16.0.0").private? => false ``` If IPAddr#private? is used in a critical code path, not supporting IPv4-mapped IPv6 addresses could lead to security issues. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113083] [Ruby master Bug#19569] #map on Enumerator::Lazy block arguments differ from regular #map
by TomNaessens (Tom Naessens) 21 Jun '23

21 Jun '23

Issue #19569 has been reported by TomNaessens (Tom Naessens). ---------------------------------------- Bug #19569: #map on Enumerator::Lazy block arguments differ from regular #map https://bugs.ruby-lang.org/issues/19569 * Author: TomNaessens (Tom Naessens) * Status: Open * Priority: Normal * ruby -v: 3.0.5...3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- A Ruby 2 to 3 upgrade surfaced the following issue: Ruby 2: ``` irb(main):252:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map(&:last).to_a => [:a, :b, :c] ``` Ruby 3: ``` irb(main):020:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map(&:last).to_a (irb):20:in `each': undefined method `last' for 1:Integer (NoMethodError) ``` Debugging the issue, I noticed the following: Map with a block returns only the first argument (and seems to ignore the zipped list): ``` irb(main):024:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map { |x| x }.to_a => [1, 2, 3] ``` It's not actually ignored though, it's just passed as a second argument: ``` irb(main):025:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map { |*x| x }.to_a => [[1, :a], [2, :b], [3, :c]] ``` Thus, this looks like a workaround: ``` irb(main):026:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map { |*x| x.last }.to_a => [:a, :b, :c] ``` But it behaves differently when leaving the `lazy` out: ``` irb(main):027:0> [1, 2, 3].to_enum.zip([:a, :b, :c]).map { |*x| x.last }.to_a => [[1, :a], [2, :b], [3, :c]] ``` Not sure if I'm correct in my conclusion, but to me it looks like the argument handling of `map` and `lazy_map` differs in an unexpected manner. Is this a bug/oversight, or I am simply using the different map implementations wrong? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111678] [Ruby master Feature#19315] Lazy substrings in CRuby
by Eregon (Benoit Daloze) 21 Jun '23

21 Jun '23

Issue #19315 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #19315: Lazy substrings in CRuby https://bugs.ruby-lang.org/issues/19315 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- CRuby should implement lazy substrings, i.e., "abcdef"[1..3] must not copy bytes. Currently CRuby only reuse the char* if the substring is until the end of the buffer. But it should also work wherever the substring starts and ends. Yes, it means RSTRING_PTR() might need to allocate to \0-terminate, so be it, it's worth it. There is already code for this (`SHARABLE_MIDDLE_SUBSTRING`), but it's disabled by default and `RSTRING_PTR()` needs to be changed to deal with this. It seems a good idea to introduce a variant of `RSTRING_PTR` which doesn't guarantee \0-termination, so such callers can then use the existing bytes always without copy. There are countless workarounds for this missing optimization, all not worth and all less readable: * https://bugs.ruby-lang.org/issues/19314 * https://github.com/ruby/net-protocol/pull/14 * Manual lazy substrings which track string + index + length * More but I don't remember all now, feel free to comment or link more urls/tickets. -- https://bugs.ruby-lang.org/

7 10

[ruby-core:113238] [Ruby master Misc#19599] DevMeeting-2023-05-10
by mame (Yusuke Endoh) 20 Jun '23

20 Jun '23

Issue #19599 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19599: DevMeeting-2023-05-10 https://bugs.ruby-lang.org/issues/19599 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/05/10 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 2023/05/07. 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/

14 13

[ruby-core:113715] [Ruby master Bug#19701] The rb_classext_t::classpath field is not marked for T_ICLASS
by wks (Kunshan Wang) 18 Jun '23

18 Jun '23

Issue #19701 has been reported by wks (Kunshan Wang). ---------------------------------------- Bug #19701: The rb_classext_t::classpath field is not marked for T_ICLASS https://bugs.ruby-lang.org/issues/19701 * Author: wks (Kunshan Wang) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I am hacking Ruby to dump information about some objects, and I found that the `rb_classext_t::classpath` field for `T_ICLASS` objects sometimes contains dangling references to dead objects. The commit https://github.com/ruby/ruby/commit/081cc4eb283cb01ddffb364397e5175dbfacab66 set the `classpath` field of `rb_mRubyVMFrozenCore` to a string "FrozenCore" so that it can be dumped using the `rb_dump_literal` function. However, in `gc_mark_children`, if the `obj` is a `T_ICLASS`, the `RCLASS_EXT(obj)->classpath` will not be marked. As a result, if `rb_mRubyVMFrozenCore` is the only object that holds a reference to the string "FrozenCore", the string will be considered garbage and reclaimed during a GC, and the `classpath` will contain a dangling pointer. There are two solutions to this problem. We can take *one* of the approaches below (not both). 1. Let the GC mark the `classpath` field. I drafted a pull request here: https://github.com/ruby/ruby/pull/7875 2. Revert the commit https://github.com/ruby/ruby/commit/081cc4eb283cb01ddffb364397e5175dbfacab66 Marking the `classpath` field in GC will keep the `rb_dump_literal` function working. For debug purposes, we can also use that field to identify what object a given `T_ICLASS` is. Adding one marked field may make GC slower, but I don't think it will be observable because there are far less `T_ICLASS` objects than ordinary objects. If we reverting the commit above, the `classpath` will always be blank for all `T_ICLASS` objects. (Question: How do we enforce it?) It will also save some memory by keeping less strings alive. However, currently, "FrozenCore" seems to be the only `T_OBJECT` that has its classpath set, and it may not result in significant memory saving. I don't know what purpose the `rb_dump_literal` function originally served. Maybe it is still important. Maybe it is safe to remove now. Which of the two approaches should we take? It looks like each of them has its pros and cons. -- https://bugs.ruby-lang.org/

4 3