[#113435] [Ruby master Feature#19634] Pattern matching dynamic key — "baweaver (Brandon Weaver) via ruby-core" <ruby-core@...>
Issue #19634 has been reported by baweaver (Brandon Weaver).
6 messages
2023/05/09
[#113489] [Ruby master Bug#19642] Remove vectored read/write from `io.c`. — "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>
Issue #19642 has been reported by ioquatix (Samuel Williams).
10 messages
2023/05/15
[ruby-core:113575] [Ruby master Bug#19681] The final classpath of partially named modules is sometimes inconsistent once permanently named
From:
"byroot (Jean Boussier) via ruby-core" <ruby-core@...>
Date:
2023-05-21 10:51:33 UTC
List:
ruby-core #113575
Issue #19681 has been updated by byroot (Jean Boussier). > has test coverage here, therefore this is deliberate. Note that this isn't necessarily true. The spec was added by Alan as part of an optimization, but that doesn't mean it was necessarily intended behavior, as in it was trying to preserve the existing behavior, which itself wasn't necessarily desirable in the first place. It's more calcification of existing behavior rather than deliberate design. Anyway, I'll try to sum up the issue and bring it to the next meeting. ---------------------------------------- Bug #19681: The final classpath of partially named modules is sometimes inconsistent once permanently named https://bugs.ruby-lang.org/issues/19681#change-103207 * 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/ ______________________________________________ ruby-core mailing list -- [email protected] To unsubscribe send an email to [email protected] ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/