[ruby-core:113530] [Ruby master Bug#19681] The final classpath of partially named modules is sometimes inconsistent once permanently named

Issue #19681 has been updated by ioquatix (Samuel Williams).


Would it make sense to store insertion order or otherwise store the order (or what is an alias) so that the constant names could be resolved correctly?

----------------------------------------
Bug #19681: The final classpath of partially named modules is sometimes inconsistent once permanently named
https://bugs.ruby-lang.org/issues/19681#change-103157

* 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 -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/