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

Can't find impl for type involving & #5050

Closed
jdm opened this issue Feb 20, 2013 · 3 comments
Closed

Can't find impl for type involving & #5050

jdm opened this issue Feb 20, 2013 · 3 comments
Labels
A-trait-system Area: Trait system

Comments

@jdm
Copy link
Contributor

jdm commented Feb 20, 2013

rusti> trait Tr { fn foo(&self); }
()
rusti>  impl Tr for &int { fn foo(&self) {} }
()
rusti> fn foo<T: Tr>(a: &T) { a.foo(); }
()
rusti> foo(&5);
<anon>:45:0: 45:3 error: failed to find an implementation of trait @main::Tr for <V1>

There are similarly confusing errors involving unsafe pointers, but I haven't figured out a good testcase yet.

@ghost ghost assigned catamorphism Feb 21, 2013
@bstrie
Copy link
Contributor

bstrie commented May 6, 2013

I'm not sure if this is a bug. Here's an updated test case:

trait Tr {
    fn foo(&self);
}

impl<'self> Tr for &'self int {
    fn foo(&self) {
        println("hello");
    }
}

fn foo<T: Tr>(a: &T) { a.foo(); }

fn main() {
    foo(&5);
}

...which fails to compile with error: failed to find an implementation of trait Tr for int.

However, if you change the foo(&5); to foo(& &5);, this prints "hello" as expected. Is this actually a bug, or is it just a complication of autoderef?

@nikomatsakis
Copy link
Contributor

On Mon, May 06, 2013 at 12:40:38PM -0700, Ben Striegel wrote:

However, if you change the foo(&5); to foo(& &5);, this prints
"hello" as expected. Is this actually a bug, or is it just a
complication of autoderef?

I don't believe this is a bug. T here is &int, so an &&int is expected.
The correct way to do this is to impl Ty for int, not &int.

@alexcrichton
Copy link
Member

It appears that the consensus is that this isn't a bug, so I'm closing for now.

flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 24, 2020
…st, r=flip1995

Change the criteria of `interior_mutable_const`

This implements my suggestion [here](rust-lang/rust-clippy#5050 (comment)), and so hopefully fixes rust-lang#5050.

* stop linting associated types and generic type parameters
* start linting ones in trait impls
  whose corresponding definitions in the traits are generic
* remove the `is_copy` check
  as presumably the only purpose of it is to allow
  generics with `Copy` bounds as `Freeze` is internal
  and generics are no longer linted
* remove the term 'copy' from the tests
  as being `Copy` no longer have meaning

---

changelog: Change the criteria of `declare_interior_mutable_const` and `borrow_interior_mutable_const` to narrow the lints to only lint things that defenitly is a interior mutable type, not potentially.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-trait-system Area: Trait system
Projects
None yet
Development

No branches or pull requests

5 participants