-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Comments
cc @eddyb this would be pretty convenient. |
@cmr we have to see how @nikomatsakis intends to improve method lookup. Though I have to point out that the 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). |
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. |
@alexcrichton updated example is working with a recent version: rustc 0.13.0-dev (97a57ec90 2014-11-07 11:31:25 +0000) I think |
Looks to be so, thanks @japaric! Flagging as needstest. |
Closes rust-lang#5988. Closes rust-lang#10176. Closes rust-lang#10456. Closes rust-lang#12744. Closes rust-lang#13264. Closes rust-lang#13324. Closes rust-lang#14182. Closes rust-lang#15381. Closes rust-lang#15444. Closes rust-lang#15480. Closes rust-lang#15756. Closes rust-lang#16822. Closes rust-lang#16966. Closes rust-lang#17351. Closes rust-lang#17503. Closes rust-lang#17545. Closes rust-lang#17771. Closes rust-lang#17816. Closes rust-lang#17897. Closes rust-lang#17905. Closes rust-lang#18188. Closes rust-lang#18232. Closes rust-lang#18345. Closes rust-lang#18389. Closes rust-lang#18400. Closes rust-lang#18502. Closes rust-lang#18611. Closes rust-lang#18783. Closes rust-lang#19009. Closes rust-lang#19081. Closes rust-lang#19098. Closes rust-lang#19127. Closes rust-lang#19135.
Closes rust-lang#5988. Closes rust-lang#10176. Closes rust-lang#10456. Closes rust-lang#12744. Closes rust-lang#13264. Closes rust-lang#13324. Closes rust-lang#14182. Closes rust-lang#15381. Closes rust-lang#15444. Closes rust-lang#15480. Closes rust-lang#15756. Closes rust-lang#16822. Closes rust-lang#16966. Closes rust-lang#17351. Closes rust-lang#17503. Closes rust-lang#17545. Closes rust-lang#17771. Closes rust-lang#17816. Closes rust-lang#17897. Closes rust-lang#17905. Closes rust-lang#18188. Closes rust-lang#18232. Closes rust-lang#18345. Closes rust-lang#18389. Closes rust-lang#18400. Closes rust-lang#18502. Closes rust-lang#18611. Closes rust-lang#18783. Closes rust-lang#19009. Closes rust-lang#19081. Closes rust-lang#19098. Closes rust-lang#19127. Closes rust-lang#19135.
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.
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
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
whenFoo
clearly implementsBaz
The text was updated successfully, but these errors were encountered: