Pick most specific parent class during linearization

[vinistock]

Motivation

Closes #3513

Since the order of file discovery during indexing does not necessarily match the require order, we may end up discovering a re-opening of an existing class before its initial definition.

In re-openings, it's quite common to omit the parent class. Currently, we're incorrectly just finding the parent class based on the first one we can find, but that means that if the re-opening was indexed first we ignore the real parent class.

Implementation

I changed the loop that we use to find parent classes to prefer specific parent classes that aren't the implicit default (::Object). That way, if there's a more specific definition of the class, we find that one - which is the one that's actually setting the parent.

Note: if the developer makes a mistake and defines the same class with two different parents, we will linearize based on the first one found. I believe this is acceptable since Ruby will raise when you try to do this.

Automated Tests

Added a test that reproduces the behaviour.

[vinistock]

• Pick most specific parent class during linearization #3572 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add the label graphite-merge to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.