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

Reject generic self types. #130098

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Commits on Sep 8, 2024

  1. Reject generic self types.

    The RFC for arbitrary self types v2 declares that we should reject
    "generic" self types. This commit does so.
    
    The definition of "generic" was unclear in the RFC, but has been
    explored in
    rust-lang#129147
    and the conclusion is that "generic" means any `self` type which
    is a type parameter defined on the method itself, or references
    to such a type.
    
    This approach was chosen because other definitions of "generic"
    don't work. Specifically,
    * we can't filter out generic type _arguments_, because that would
      filter out Rc<Self> and all the other types of smart pointer
      we want to support;
    * we can't filter out all type params, because Self itself is a
      type param, and because existing Rust code depends on other
      type params declared on the type (as opposed to the method).
    
    This PR decides to make a new error code for this case, instead of
    reusing the existing E0307 error. This makes the code a
    bit more complex, but it seems we have an opportunity to provide
    specific diagnostics for this case so we should do so.
    
    This PR filters out generic self types whether or not the
    'arbitrary self types' feature is enabled. However, it's believed
    that it can't have any effect on code which uses stable Rust, since
    there are no stable traits which can be used to indicate a valid
    generic receiver type, and thus it would have been impossible to
    write code which could trigger this new error case.
    It is however possible that this could break existing code which
    uses either of the unstable `arbitrary_self_types` or
    `receiver_trait` features. This breakage is intentional; as
    we move arbitrary self types towards stabilization we don't want
    to continue to support generic such types.
    
    This PR adds lots of extra tests to arbitrary-self-from-method-substs.
    Most of these are ways to trigger a "type mismatch" error which
    https://github.com/rust-lang/rust/blob/9b82580c7347f800c2550e6719e4218a60a80b28/compiler/rustc_hir_typeck/src/method/confirm.rs#L519
    hopes can be minimized by filtering out generics in this way.
    We remove a FIXME from confirm.rs suggesting that we make this change.
    It's still possible to cause type mismatch errors, and a subsequent
    PR may be able to improve diagnostics in this area, but it's harder
    to cause these errors without contrived uses of the turbofish.
    
    This is a part of the arbitrary self types v2 project,
    rust-lang/rfcs#3519
    rust-lang#44874
    
    r? @wesleywiser
    adetaylor committed Sep 8, 2024
    Configuration menu
    Copy the full SHA
    5dfbacc View commit details
    Browse the repository at this point in the history