…the path. This fixes no reported issue
For this bug, we had the unusual case where a child class had the same name as its parent. This caused the class reification to fail since the parent class had to be reified first, and then the child conflicted with that name. A reproduction case looks like this: module Bar class Foo; end end foo = Bar::Foo Bar.send :remove_const, :Foo Bar.const_set :Foo, Class.new(foo) Bar::Foo.new Here, the new Bar::Foo extends the old Bar::Foo, but takes on its name when assigned to the Foo constant. As a result, we have two classes in the same class hierarchy with the same fully-qualified name. A few options were considered to fix this: * Bail out when there's such a conflict, since they should be rare occurences. That's this commit. * Attach the class's ID to all reified class names. That also fixes this issue, but make all reified classes suddenly have a potentially unpredictable ID number attached. * Only attach the class's ID to the reified class name in the case of this unusual collision. The ID would still be unpredictable, but under most normal circumstances it would not be used. I opted for the first case, since these peculiar child classes will still use their reified parent (of the same name) and this change does not introduce any unpredictable aspect to the reified class names. We may revisit this in the future.
…y into lucasallan-issue-1177-string-concat
* LVA information is invalid after most passes that modifies the instruction list of a scope. * This fix eliminates crashers when passes are run in non-default orders.