arbitrary_self_types: Split the Autoderef chain #146095

dingxiangfei2009 · 2025-09-01T16:02:27Z

Receiver chain has been an extension of Deref chain, but the consequence has been questioned as this would admit method signatures that are deemed dubious.

It is also debatable that Receiver trait which determines applicable Self type should have anything to do with dereference operation in general.

This patch separate the two traits and isolate their use in the language. This means that in method probing, we will chase down a Deref chain for an applicable type for the variable self, from which we additionally chase down a Receiver chain for an applicable Self type from a list of methods that accepts one of these possible types of self.

To facilitate discussion, we can use the Zulip thread #t-lang > Consequences of making Deref a subtrait of Receiver.

Pending items

First, gather feedback on the proposed change and assess the impact on the overall feature.
Stomp out UI test changes due to lost diagnostics, by enabling search through Receiver side-chains, so that we can suggest enabling arbitrary_self_types gate again.

rustbot · 2025-09-01T16:02:32Z

r? @jackh726

rustbot has assigned @jackh726.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-09-01T16:02:35Z

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

dingxiangfei2009 · 2025-09-02T07:49:51Z

@rustbot label +F-arbitrary_self_types

rustbot · 2025-09-02T08:44:34Z

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

jackh726 · 2025-09-03T17:02:42Z

Is this waiting on discussion and a decision from the lang team?

dingxiangfei2009 · 2025-09-04T11:11:37Z

@jackh726 Sorry I was not very clear. Indeed it would need a lang team discussion.

To support the discussion, I am writing a report to describe what changes this would bring to the feature.

cc @traviscross @tmandry

bors · 2025-09-18T18:06:35Z

☔ The latest upstream changes (presumably #145993) made this pull request unmergeable. Please resolve the merge conflicts.

dingxiangfei2009 · 2025-09-24T18:21:23Z

The report is a bit overdue. I would like to just publish a partial text while I need more time to restore some diagnostics.

Acceptable receivers

Landing #146095 means that types implementing Deref are not automatically acceptable receiver types anymore.

Before #146095

After #146095

struct A;
struct B;
impl Deref for A {
    type Target = B;
    fn deref(&self) -> &B {
        &B
    }
}
impl B {
    fn recv(self: &A);
}

A.recv(); // resolves to B::recv

struct A;
struct B;
impl Deref for A {
    type Target = B;
    fn deref(&self) -> &B {
        &B
    }
}
// This is needed ...
impl Receiver for A {
    type Target = B;
}
impl B {
    fn recv(self: &A);
}

A.recv();
// ^ ... in order to resolve this to B::recv

// The following passes checking in our surprises
impl Trait for str {
    fn recv(self: &String) {}
}
"hello".to_string().recv();
impl Trait for MyType {
    fn recv(self: MutexGuard<'_, Self>) {}
}
let my_mutex = Mutex::new(MyType);
my_mutex.lock().recv();

// The following stops to compile for good reasons
impl Trait for str {
    fn recv(self: &String) {}
    // `String: Deref<Target = str>` but without `Receiver<Target = str>`
}
"hello".to_string().recv(); //~ ERROR
impl Trait for MyType {
    fn recv(self: MutexGuard<'_, Self>) {}
    // `MutexGuard<'_, MyType>: Deref<Target = MyType>` but without `Receiver<Target = MyType>`
}
let my_mutex = Mutex::new(MyType);
my_mutex.lock().recv(); //~ ERROR

Library changes

This patch demonstrates that we now explicitly mark types like Rc, Arc, Box, Pin as valid receivers regardless of whether a Deref is applicable.

This is particularly important for Pin as we want to conditionally make it Derefable but unconditionally a valid method receiver just like the stable Rust.

Shadowing

After careful consideration and testing, I believe that splitting the two traits do not change the fundamental reasoning behind method shadowing diagnostics. Before this change, concerns about shadowing items through Deref, and by extension Receiver, are reported by the compiler by picking up inherent methods with the same name on some self receiver down the Receiver chain. Those shadowed items will continue to be reported as they will appear in the same Receiver sub-chain after this PR lands.

traviscross · 2025-09-24T19:54:44Z

I'm going to go ahead and nominate. This is just a vibe check. We're not making a binding decision at this time. The question on the table is only whether we might have such opposition to this direction that we'd block or discourage its exploration.

For my part, I want to see this explored so we can fully consider it.

rustbot · 2025-10-05T19:56:31Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

traviscross · 2025-10-05T21:50:18Z

We talked about this, for a vibe check, in the lang meeting this past week. People certainly aren't yet sold on this approach -- I'm not yet sold myself. However, I feel that the way to work out whether this approach is viable and desirable is to let @dingxiangfei2009 land this and explore it further -- experimentation will hopefully help to answer the kind of questions this approach raises and support the writing of comprehensive design documents for this -- and that went without objection.

Putting on the hat of the lang champion here, then, this PR is OK to land as far as lang is concerned.

We'll want to be careful, in how we do this experimentation, that we still support experimentation of and the ability to answer important design questions for the other model, e.g. to support work on evolving trait hierarchies, reborrowing, autoref, projection, etc., where we might want to compare how the complete solution would look either in the Deref::Target == Receiver::Target world or in the other one. I'm hopeful that we can add additional feature flags as necessary in order to support whatever turns out to be needed here.

rustbot · 2025-10-09T08:15:02Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Receiver chain has been an extension of Deref chain, but the consequence has been questioned as this would admit method signatures that are deemed dubious. It is also debatable that Receiver trait which determines applicable `Self` type should have anything to do with dereference operation in general. This patch separate the two traits and isolate their use in the language. This means that in method probing, we will chase down a Deref chain for an applicable type for the variable `self`, from which we additionally chase down a Receiver chain for an applicable `Self` type from a list of methods that accepts one of these possible types of `self`.

jackh726

Wasn't sure if this was quite ready for review or not. But, here are my thoughts.

View changes since this review

jackh726 · 2025-10-29T00:32:02Z

compiler/rustc_hir_analysis/messages.ftl


 hir_analysis_invalid_receiver_ty_help_no_arbitrary_self_types =
-    consider changing to `self`, `&self`, `&mut self`, `self: Box<Self>`, `self: Rc<Self>`, `self: Arc<Self>`, or `self: Pin<P>` (where P is one of the previous types except `Self`)
+    consider changing to `self`, `&self`, `&mut self`, `self: Box<Self>`, `self: Rc<Self>`, `self: Arc<Self>`, or `self: Pin<P>` (where P is one of the previous types except `Self`);


I'm surprised by this change. I would expect to only change the diagnostic when the feature is not enabled hir_analysis_invalid_receiver_ty_help

jackh726 · 2025-10-29T01:41:06Z

compiler/rustc_hir_typeck/src/method/confirm.rs

+                    A(A, PhantomData<fn() -> C>),
+                    B(B, PhantomData<fn() -> C>),


Why the extra PhantomData<fn() -> C> here? I assume it was to ensure that C is used constrained in the impl below, but it's unnecessary.

jackh726 · 2025-10-29T01:46:29Z

compiler/rustc_hir_typeck/src/method/confirm.rs

+                    }
+                }
+                if follow_receiver_chain {
+                    EitherIter::A(fcx.autoderef(span, ty).follow_receiver_chain(), PhantomData)


Okay, so if I'm understanding this correctly, for each step in Deref chain, we then try a Receiver chain? That's pretty crazy, and is very likely going to have an effect on perf.

I would really like to evaluate perf before and after this PR (when enabling arbitrary self types).

jackh726 · 2025-10-29T01:47:50Z

compiler/rustc_hir_analysis/src/check/wfcheck.rs

+        // We are in the wf check, so we would like to deref the references in the type head.
+        // However, we do not want to walk `Deref` chain.
+        autoderef = autoderef.follow_receiver_chain();


I'm curious why that is here? But in confirm we do?

jackh726 · 2025-10-29T01:49:27Z

compiler/rustc_codegen_cranelift/example/arbitrary_self_types_pointers_and_wrappers.rs

        &*self.0
    }
 }
+impl<T: ?Sized> Receiver for Ptr<T> {


Are these impls required? I imagine this might be a consequence of my comment in wfcheck?

rustbot assigned jackh726 Sep 1, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 1, 2025