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

Generic impls of traits don't autoderef #10456

Closed
alexcrichton opened this issue Nov 13, 2013 · 5 comments · Fixed by #19780
Closed

Generic impls of traits don't autoderef #10456

alexcrichton opened this issue Nov 13, 2013 · 5 comments · Fixed by #19780
Labels
A-traits Area: Trait system E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.

Comments

@alexcrichton
Copy link
Member

pub struct Foo;

pub trait Bar {
    fn bar(&self);
}

pub trait Baz {}

impl<T: Baz> Bar for T {
    fn bar(&self) {}
}

impl Baz for Foo {}

pub fn foo(t: ~Foo) {
    t.bar() // ~Foo doesn't implement Baz
    (*t).bar() // ok b/c Foo implements Baz
}

fn main() {}

From a code-writer point of view, it'd be nice for t to auto-deref to (*t).bar() to appease the compiler, but I can see that the compiler may not know a whole lot about this.

If we don't get auto-deref here, perhaps a better error message may work. It's a little confusing to see that ~Foo doesn't implement Baz when Foo clearly implements Baz

@emberian
Copy link
Member

emberian commented Apr 7, 2014

cc @eddyb

this would be pretty convenient.

@eddyb
Copy link
Member

eddyb commented Apr 7, 2014

@cmr we have to see how @nikomatsakis intends to improve method lookup.

Though I have to point out that the X doesn't implement Y error comes from vtable checking which comes after type-checking finishes, and I'm pretty sure it has access to concrete types (without type inference variables at least. region inference isn't resolved until after regionck).

That said, if the type information is available at the time of the method lookup, the vtable error can be prevented by searching for another suitable candidate (but this would also complicate simpler cases).

@nikomatsakis
Copy link
Contributor

This actually has nothing to do with auto-deref, but it is addressed by the method lookup algorithm that I'm working on. That is ALMOST ready for publication, just working on the last bits.

@japaric
Copy link
Member

japaric commented Nov 7, 2014

@alexcrichton updated example is working with a recent version:

rustc 0.13.0-dev (97a57ec90 2014-11-07 11:31:25 +0000)

I think Box<T> now derefs to &T although Box<T> doesn't implement Deref<T> (#18624)

@alexcrichton
Copy link
Member Author

Looks to be so, thanks @japaric! Flagging as needstest.

@alexcrichton alexcrichton added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Nov 7, 2014
bors added a commit that referenced this issue Dec 18, 2014
Closes #5988.
Closes #10176.
Closes #10456.
Closes #12744.
Closes #13264.
Closes #13324.
Closes #14182.
Closes #15381.
Closes #15444.
Closes #15480.
Closes #15756.
Closes #16822.
Closes #16966.
Closes #17351.
Closes #17503.
Closes #17545.
Closes #17771.
Closes #17816.
Closes #17897.
Closes #17905.
Closes #18188.
Closes #18232.
Closes #18345.
Closes #18389.
Closes #18400.
Closes #18502.
Closes #18611.
Closes #18783.
Closes #19009.
Closes #19081.
Closes #19098.
Closes #19127.
Closes #19135.
flip1995 pushed a commit to flip1995/rust that referenced this issue Mar 24, 2023
Issue function modifiers in the right order in manual_async_fn lint

Fixes rust-lang#10450

changelog: [`manual_async_fn`] output function modifiers in correct order
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-traits Area: Trait system E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants