Closed
Description
Up to version 1.83 the following code compiled successfully:
Code
#![feature(arbitrary_self_types)]
struct Foo;
impl Foo {
fn foo(self: &impl std::ops::Deref<Target = Self>) {}
}
With version 1.84 we get the following error:
error[E0801]: invalid generic `self` parameter type: `&impl std::ops::Deref<Target = Self>`
...
note: "type of `self` must not be a method generic parameter type"
Version it worked on
It most recently worked on: 1.83
Version with regression
rustc --version --verbose
:
rustc 1.84.0 (9fc6b4312 2025-01-07)
binary: rustc
commit-hash: 9fc6b43126469e3858e2fe86cafb4f0fd5068869
commit-date: 2025-01-07
host: aarch64-apple-darwin
release: 1.84.0
LLVM version: 19.1.5
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
Noratrieb commentedon Jan 13, 2025
I assume this is expected and not a bug, but it would be good to confirm that, I recommend using cargo-bisect-rustc to figure out which PR made this info an error.
schreter commentedon Jan 13, 2025
What do you mean with "info"? Previously, it didn't generate any message, no warnings or so. It was correctly compiled and worked as expected. So I'd personally see this as a regression/error.
Noratrieb commentedon Jan 13, 2025
I meant "into" that was a typo. This is an unstable feature, so it is expected to change. I know there were some recent changes to it which have probably causes this. That's why I asked for a bisection, so we can find the PR that regressed this, which will probably tell us whether it was an accidental regression (and therefore a bug) or an expected change (not a bug).
ranger-ross commentedon Jan 13, 2025
bisects to #130098 in
nightly-2024-10-31
ranger-ross commentedon Jan 13, 2025
@rustbot label +S-has-bisection -E-needs-bisection
Noratrieb commentedon Jan 13, 2025
Thank you for the bisection. Yeah that look very intentional. You will need to change your code to remove the use of generic self types.
johamster commentedon Jan 13, 2025
Ack, thanks for the clarification. Will close the bug.
schreter commentedon Jan 13, 2025
Thanks for the explanation why the error happens. I looked at the reasoning in the relevant threads. Basically, the feature does work with generic self types w/o problems, the worries are with people using explicit generics via turbofish operator, which potentially causes strange compile errors.
Would it be at least possible to allow something like
fn method(self: &impl SomethingImplementingDeref<Target = Self>)
, i.e., implicit generic, where there is no possibility explicitly specify the type?Background: We have a set of handle types all implementing a
trait Handle: Deref + Clone
and want to declare a method working on all handle types. So far, it worked withfn method(self: &impl Handle<Target = Self>)
.Noratrieb commentedon Jan 14, 2025
I'd recommend opening a new issue about that topic