Skip to content

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

Closed
@johamster

Description

@johamster

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

Activity

added
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on Jan 13, 2025
removed
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
regression-untriagedUntriaged performance or correctness regression.
on Jan 13, 2025
Noratrieb

Noratrieb commented on Jan 13, 2025

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

added
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
E-needs-bisectionCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc
and removed
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on Jan 13, 2025
schreter

schreter commented on Jan 13, 2025

@schreter

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

Noratrieb commented on Jan 13, 2025

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

ranger-ross commented on Jan 13, 2025

@ranger-ross
Contributor

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

ranger-ross

ranger-ross commented on Jan 13, 2025

@ranger-ross
Contributor

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

added
S-has-bisectionStatus: A bisection has been found for this issue
and removed
E-needs-bisectionCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc
on Jan 13, 2025
Noratrieb

Noratrieb commented on Jan 13, 2025

@Noratrieb
Member

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.

added
C-discussionCategory: Discussion or questions that doesn't represent real issues.
T-langRelevant to the language team
and removed
C-bugCategory: This is a bug.
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on Jan 13, 2025
johamster

johamster commented on Jan 13, 2025

@johamster
Author

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

schreter

schreter commented on Jan 13, 2025

@schreter

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

Noratrieb commented on Jan 14, 2025

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-discussionCategory: Discussion or questions that doesn't represent real issues.F-arbitrary_self_types`#![feature(arbitrary_self_types)]`S-has-bisectionStatus: A bisection has been found for this issueT-langRelevant to the language team

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @johamster@ranger-ross@schreter@rustbot@Noratrieb

        Issue actions

          `#![feature(arbitrary_self_types)]` - "type of `self` must not be a method generic parameter type" · Issue #135429 · rust-lang/rust