arbitrary_self_types: Split the Autoderef chain

[dingxiangfei2009]

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]

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]

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]

@rustbot label +F-arbitrary_self_types

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[jackh726]

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

[dingxiangfei2009]

@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]

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

[dingxiangfei2009]

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]

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]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[rustbot]

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.

[traviscross]

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.

[rust-log-analyzer]

The job aarch64-gnu-llvm-20-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- [mir-opt] tests/mir-opt/building/receiver_ptr_mutability.rs stdout ----
------rustc stdout------------------------------

------rustc stderr------------------------------
error[E0599]: no method named `x` found for reference `&&&&*mut Test` in the current scope
##[error]  --> /checkout/tests/mir-opt/building/receiver_ptr_mutability.rs:21:13
   |
21 |     ptr_ref.x();
   |             ^ method not found in `&&&&*mut Test`

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0599`.

------------------------------------------

error: compilation failed!
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/mir-opt/building/receiver_ptr_mutability.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2" "--target=aarch64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "-O" "-Copt-level=1" "-Zdump-mir=built" "-Zvalidate-mir" "-Zlint-mir" "-Zdump-mir-exclude-pass-number" "-Zmir-include-spans=false" "--crate-type=rlib" "-Zmir-opt-level=4" "-Zmir-enable-passes=+ReorderBasicBlocks,+ReorderLocals" "-Zdump-mir-dir=/checkout/obj/build/aarch64-unknown-linux-gnu/test/mir-opt/building/receiver_ptr_mutability" "--emit" "mir" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/mir-opt/building/receiver_ptr_mutability" "-A" "internal_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Cdebuginfo=0" "-Zmir-opt-level=0"
stdout: none
--- stderr -------------------------------
error[E0599]: no method named `x` found for reference `&&&&*mut Test` in the current scope
##[error]  --> /checkout/tests/mir-opt/building/receiver_ptr_mutability.rs:21:13
   |
21 |     ptr_ref.x();
   |             ^ method not found in `&&&&*mut Test`

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0599`.
------------------------------------------