Add receiver to MethodAliasDefinition by alexcrocha · Pull Request #645 · Shopify/rubydex

alexcrocha · 2026-03-05T21:35:38Z

This PR resolves a gap identified in #631 (comment)

alias_method can be called on a specific class, like Foo.alias_method(:new, :old). When that happens, the alias belongs to Foo rather than whatever class happens to be the enclosing scope. Adding a receiver field to MethodAliasDefinition lets the resolver figure out the right owner.

Unlike def Foo.bar which defines a singleton method, Foo.alias_method always creates instance aliases. So we resolve constant receivers to the class itself, not its singleton class.

This PR also extracts resolve_singleton_owner, create_singleton_name_id, and Receiver::append_to_id to reduce duplication, and moves the receiver guard out of each_string_or_symbol_arg into index_attr since alias_method legitimately accepts constant receivers now.

alexcrocha · 2026-03-05T21:35:55Z

Index method aliases with RBS indexer #631
Add receiver to MethodAliasDefinition #645 👈 (View in Graphite)
main

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

rust/rubydex/src/indexing/ruby_indexer.rs

rust/rubydex/src/resolution.rs

vinistock · 2026-03-06T14:28:06Z

rust/rubydex/src/indexing/ruby_indexer.rs

+                let receiver = receiver_node.as_ref().and_then(|node| match node {
+                    ruby_prism::Node::ConstantPathNode { .. } | ruby_prism::Node::ConstantReadNode { .. } => self
+                        .index_constant_reference(node, true)
+                        .map(Receiver::ConstantReceiver),
+                    _ => None,
+                });
+
+                // alias_method references instance methods, so we use the class NameId directly
+                let method_ref_receiver = match &receiver {
+                    Some(Receiver::ConstantReceiver(name_id)) => Some(*name_id),
+                    Some(Receiver::SelfReceiver(_)) | None => {
+                        self.method_receiver(receiver_node.as_ref(), node.location())
+                    }
+                };


Why do we need these two separate paths for the receiver? It seems you're handling constant receiver in one and self in the other. Doesn't method_receiver already handle both?

The old method_receiver() wrapped constant receivers into a singleton class, so we couldn't reuse it directly for alias_method.

Taking a deeper look at the problem, I split the responsibilities: method_receiver() now only classifies what kind of receiver it is (returning a Receiver enum), and extracted the rest into index_method_receiver(), which creates the singleton class name and indexes the constant reference.

I wasn't happy with how the code was turning out and noticed there were a few concepts tied together, which led me to refactor the Receiver enum to better handle the different scenarios.

Since this is an unexpected refactor, it's in a different commit for an easier review.
Let me know if you have any questions.

rust/rubydex/src/indexing/ruby_indexer.rs

vinistock · 2026-03-06T14:29:49Z

rust/rubydex/src/model/definitions.rs


 /// The receiver of a singleton method definition.
-#[derive(Debug)]
+#[derive(Debug, Clone, Copy)]


Why do we need to clone and copy receivers?

Before this PR, the receiver handling was inline within each match arm, so there was no borrow conflict.

Extracting resolve_singleton_owner as a shared helper to remove duplication means we now need to pass the receiver to a &mut self method while self.graph.definitions() is still borrowed.

Copy lets us dereference the receiver out of the borrow (let receiver = *method_definition.receiver()), which I find cleaner than .clone()

rust/rubydex/src/model/definitions.rs

rust/rubydex/src/resolution.rs

st0012 · 2026-03-09T14:43:26Z

rust/rubydex/src/indexing/ruby_indexer.rs

+    Constant(NameId),
+    /// `singleton_class` call or method nested inside a singleton method.
+    SingletonClass(NameId),
+}


We already have Receiver enum in definitions.rs to represent receiver types. Why can't we use them here?

Stan and I pair-reviewed this PR and revisited my original choice to create a separate enum. Thanks to his feedback, we're now reusing the existing Receiver enum directly. Simpler and avoids the extra enum.

@st0012, let me know what you think of the changes.

alias_method can be called on a specific class, like Foo.alias_method(:new, :old), where the alias belongs to Foo rather than the enclosing scope. To handle this, we now store the receiver on MethodAliasDefinition so the resolver knows which class owns the alias. Since alias_method always creates instance aliases (unlike def Foo.bar which targets the singleton class), constant receivers resolve to the class itself.

Change SelfReceiver from DefinitionId to NameId — every caller already resolved through the name system, making the indirection unnecessary. Add SingletonClassReceiver variant for singleton method nesting and singleton_class calls. Split the old method_receiver() into two functions: - method_receiver() returns a Receiver (classification only) - index_method_receiver() wraps in singleton name and registers constant references, returning NameId This lets the alias_method handler call method_receiver() directly to classify the receiver without singleton wrapping, while method definitions and references continue using index_method_receiver()

st0012 · 2026-03-10T16:56:20Z

rust/rubydex/src/indexing/ruby_indexer.rs

-
-        let name_id = match receiver {
+    /// Classifies a method receiver AST node into a [`Receiver`] without applying
+    /// singleton wrapping or registering constant references.


What does the singleton wrapping mean?

st0012 · 2026-03-10T16:59:46Z

rust/rubydex/src/indexing/ruby_indexer.rs

            Some(ruby_prism::Node::CallNode { .. }) => {
-                // Check if the receiver is `singleton_class`
+                // For `Foo.singleton_class.bar`, we need the inner receiver (`Foo`) with
+                // singleton wrapping and constant reference registration. This calls


This seems to contradict what the method comment says?

st0012 · 2026-03-10T17:04:15Z

rust/rubydex/src/model/definitions.rs

-    SelfReceiver(DefinitionId),
-    /// `def Foo.bar` - receiver is an explicit constant that needs resolution
+    /// `self` or no receiver — resolved from the lexical nesting.
+    SelfReceiver(NameId),


Why are we changing this? We use DefinitionId because when the receiver relies on lexical scope, we can't immediately know the name when indexing. It could also have no name at all, for example:

foo do def self.bar; end end

We will need to preserve these definitions too for DSL handling.

st0012 · 2026-03-10T17:04:38Z

rust/rubydex/src/model/definitions.rs

-    /// `def self.foo` - receiver is the enclosing definition (class, module, singleton class or DSL)
-    SelfReceiver(DefinitionId),
-    /// `def Foo.bar` - receiver is an explicit constant that needs resolution
+    /// `self` or no receiver — resolved from the lexical nesting.


When there's no receiver, it's reflected by having None in the receiver attribute.

alexcrocha mentioned this pull request Mar 5, 2026

Index method aliases with RBS indexer #631

Open

vinistock reviewed Mar 5, 2026

View reviewed changes

rust/rubydex/src/indexing/ruby_indexer.rs Outdated Show resolved Hide resolved

rust/rubydex/src/resolution.rs Outdated Show resolved Hide resolved

alexcrocha force-pushed the 03-05-add_receiver_to_methodaliasdefinition branch 2 times, most recently from 97823c7 to 1315d61 Compare March 6, 2026 04:01

alexcrocha marked this pull request as ready for review March 6, 2026 04:07

alexcrocha requested a review from a team as a code owner March 6, 2026 04:07

alexcrocha requested a review from vinistock March 6, 2026 04:07

alexcrocha self-assigned this Mar 6, 2026

vinistock reviewed Mar 6, 2026

View reviewed changes

alexcrocha force-pushed the 03-05-add_receiver_to_methodaliasdefinition branch 5 times, most recently from e2e0984 to 3ef8701 Compare March 7, 2026 17:06

st0012 reviewed Mar 9, 2026

View reviewed changes

alexcrocha added 2 commits March 9, 2026 19:31

alexcrocha force-pushed the 03-05-add_receiver_to_methodaliasdefinition branch from 3ef8701 to 4ebcb18 Compare March 10, 2026 02:31

alexcrocha requested a review from st0012 March 10, 2026 03:00

st0012 requested changes Mar 10, 2026

View reviewed changes

Conversation

alexcrocha commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexcrocha commented Mar 5, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexcrocha Mar 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

st0012 Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

alexcrocha commented Mar 5, 2026 •

edited

Loading

alexcrocha Mar 7, 2026 •

edited

Loading

st0012 Mar 10, 2026 •

edited

Loading