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

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

24 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: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

[ruby-core:113529] [Ruby master Bug#19681] The final classpath of partially named modules is sometimes inconsistent once permanently named
by byroot (Jean Boussier) 11 Jun '23

11 Jun '23

Issue #19681 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #19681: The final classpath of partially named modules is sometimes inconsistent once permanently named https://bugs.ruby-lang.org/issues/19681 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Backport: 3.0: WONTFIX, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Reported to me by @fxn ```ruby m = Module.new class m::C; end p m::C.name # => "#<Module:0x000000010789fbe0>::C" m::D = m::C p m::D.name # => "#<Module:0x000000010789fbe0>::C" M = m p M::C.name # => "#<M::D" ``` Expected behavior: ```ruby p M::C.name # => "#<M::C" ``` ### Reason When the parent is assigned its permanent classpath, we iterate over its `const_table` to recursively give a permanent name to all the constant it owns. However, `const_table` is an `id_table` so it doesn't retain the insertion order, which means that if the constant was aliased, we can no longer distinguish between the original name and its aliases, and whichever comes first in the `const_table` will be used as the permanent name. ### Potential solution I have a tentative fix for it in https://github.com/ruby/ruby/pull/7829. Instead of relying on the `const_table` key, it extract the original name from the temporary classpath. It does feel a bit wrong to do a string search in such a place, but it does work. -- https://bugs.ruby-lang.org/

7 33

[ruby-core:113660] [Ruby master Feature#19694] Add Regexp#timeout= setter
by aharpole (Aaron Harpole) 09 Jun '23

09 Jun '23

Issue #19694 has been reported by aharpole (Aaron Harpole). ---------------------------------------- Feature #19694: Add Regexp#timeout= setter https://bugs.ruby-lang.org/issues/19694 * Author: aharpole (Aaron Harpole) * Status: Open * Priority: Normal ---------------------------------------- # Abstract In addition to allowing for a Regexp timeout to be set on individual instances by setting a `timeout` argument in `Regexp.new`, I'm proposing that we also allow setting the timeout on Regexp objects with a `#timeout=` setter. # Background To be able to roll out a global Regexp timeout for a large application, there are inevitably some individual regexes for which a different timeout is appropriate. While the `timeout` keyword argument was added to `Regexp.new`, this isn't always a viable option. In the case of regex literal syntax (`/ab*/` or `%r{ab*}`, for instance), it's not possible to set a timeout at all right now without converting to `Regexp.new`, which may be awkward depending on the contents of the regex. It also is desirable from time to time to be able to set a timeout for a regex object after it's been initialized. Finally, because we offer a `Regexp#timeout` getter, for consistency it would be nice to also offer a setter. The introduction of a `Regexp#timeout=` setter was mentioned as a possible way to set individual timeouts in https://bugs.ruby-lang.org/issues/19104#Specification. # Proposal I propose that we add the method `Regexp#timeout=`. It works the same way the `timeout` argument works in `Regexp.new`, taking either a float or nil. This makes it relatively easy to add timeouts to specific regex literals (regex literals are frozen by default so you do have to `dup` them first): ``` emoji_filter_pattern = %r{ (?<!#{Regexp.quote(ZERO_WIDTH_JOINER)}) #{EmojiFilter.unicodes_pattern} (?!#{Regexp.union(EmojiFilter::MODIFIER_CHAR_MAP.keys.map { |k| Regexp.quote k })}) }x.dup emoji_filter_pattern.timeout = 1.0 emoji_filter_pattern.freeze ``` # Implementation This setter has been implemented in https://github.com/ruby/ruby/pull/7847. # Evaluation It's just a setter, so pretty straightforward in terms of implementation and use. # Discussion It's worth considering other options for overriding `Regexp.timeout`. I'd love to see something like the following for overriding regexp timeouts as well: ``` Regexp.timeout = 1.0 Regexp.with_timeout(5.0) do evaluate_slower_regexes end ``` It's possible to implement something like `Regexp.with_timeout` but it's not thread-safe by default since it would involve overwriting `Regexp.timeout`. # Summary Regexp instances have a getter for timeout, and adding a corresponding setter adds consistency and will make it easier for developers to adopt adding a global `Regexp.timeout` by making it simpler to adjust timeouts on a regex by regex basis. It's a minor change but the added consistency and flexibility help us optimize for developer happiness. -- https://bugs.ruby-lang.org/

9 14

[ruby-core:113716] [Ruby master Bug#19702] Promote racc as bundled gems
by hsbt (Hiroshi SHIBATA) 08 Jun '23

08 Jun '23

Issue #19702 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19702: Promote racc as bundled gems https://bugs.ruby-lang.org/issues/19702 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In the past, we need to bundle `racc` runtime for RD parser of RDoc. Now, We have racc compiler and runtime in ruby repository. I'm not sure we should bundle and maintain `racc` as stdlib in the future. Can we promote `racc` to bundled gems? -- https://bugs.ruby-lang.org/

2 5

[ruby-core:112770] [Ruby master Feature#19520] Support for `Module.new(name)` and `Class.new(superclass, name)`.
by ioquatix (Samuel Williams) 08 Jun '23

08 Jun '23

Issue #19520 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- See <https://bugs.ruby-lang.org/issues/19450> for previous discussion and motivation. [This proposal](https://github.com/ruby/ruby/pull/7376) introduces the `name` parameter to `Class.new` and `Module.new`: ```ruby Class.new(superclass, name) Module.new(name) ``` As a slight change, we could use keyword arguments instead. -- https://bugs.ruby-lang.org/

8 41

[ruby-core:113587] [Ruby master Misc#19684] DevMeeting-2023-06-08
by mame (Yusuke Endoh) 07 Jun '23

07 Jun '23

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

6 5