Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#![feature(arbitrary_self_types)] - "type of self must not be a method generic parameter type" #135429

Closed
johamster opened this issue Jan 13, 2025 · 9 comments
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. F-arbitrary_self_types `#![feature(arbitrary_self_types)]` S-has-bisection Status: a bisection has been found for this issue T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@johamster
Copy link

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
@johamster johamster added C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. labels Jan 13, 2025
@rustbot rustbot added I-prioritize Issue: Indicates that prioritization has been requested for this issue. needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Jan 13, 2025
@Noratrieb Noratrieb removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. regression-untriaged Untriaged performance or correctness regression. labels Jan 13, 2025
@Noratrieb
Copy link
Member

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.

@Noratrieb Noratrieb added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. E-needs-bisection Call for participation: This issue needs bisection: /~https://github.com/rust-lang/cargo-bisect-rustc F-arbitrary_self_types `#![feature(arbitrary_self_types)]` and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Jan 13, 2025
@schreter
Copy link

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.

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
Copy link
Member

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
Copy link
Contributor

bisects to #130098 in nightly-2024-10-31

@ranger-ross
Copy link
Contributor

@rustbot label +S-has-bisection -E-needs-bisection

@rustbot rustbot added S-has-bisection Status: a bisection has been found for this issue and removed E-needs-bisection Call for participation: This issue needs bisection: /~https://github.com/rust-lang/cargo-bisect-rustc labels Jan 13, 2025
@Noratrieb
Copy link
Member

Noratrieb commented 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.

@Noratrieb Noratrieb added C-discussion Category: Discussion or questions that doesn't represent real issues. T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 13, 2025
@johamster
Copy link
Author

Ack, thanks for the clarification. Will close the bug.

@schreter
Copy link

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 with fn method(self: &impl Handle<Target = Self>).

@Noratrieb
Copy link
Member

I'd recommend opening a new issue about that topic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. F-arbitrary_self_types `#![feature(arbitrary_self_types)]` S-has-bisection Status: a bisection has been found for this issue T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants