-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
method dispatcher doesn't handle generic implementations properly #5898
Comments
Nominating for backwards-compatible, and failing that, feature-complete. |
declined for milestone, this feels like just-a-bug of some sort, probably #3429 |
Yes, this is the same bug as #3429. The underlying issue in both of them is that the initial filtering of relevant methods is not precise enough, i.e. that it treats impls such as the following as being applicable to each type, regardless whether it implements trait Foo {
fn foo(&self);
}
trait Bar {
fn bar(&self);
}
impl <T: Bar> Foo for T {
fn foo(&self) { self.bar(); }
} (This filtering currently happens in In this issue, this causes a surprising error for a type that is not connected to the relevant traits at all, in issue #3429, this causes a conflict of multiple methods, even though only one of them should be applicable. |
@graydon: I think this should have the backwards compatible milestone because it will mean renaming a bunch of methods like |
This was a lot more painful than just changing `x.each` to `x.iter().advance` . I ran into my old friend #5898 and had to add underscores to some method names as a temporary workaround. The borrow checker also had other ideas because rvalues aren't handled very well yet so temporary variables had to be added. However, storing the temporary in a variable led to dynamic `@mut` failures, so those had to be wrapped in blocks except where the scope ends immediately. Anyway, the ugliness will be fixed as the compiler issues are fixed and this change will amount to `for x.each |x|` becoming `for x.iter |x|` and making all the iterator adaptors available. I dropped the run-pass tests for `old_iter` because there's not much point in fixing a module that's on the way out in the next week or so.
The annoying method resolve bug with generic implementations is still around (#5898), but the conflicts ended up being resolved by adding underscores as a hack, in previous commits.
…h StrVector. This is caused by StrVector having a generic implementation for &[S] and so rust-lang#5898 means that method resolution of ~[~[1]].concat() sees that both StrVector and VectorVector have methods that (superficially) match. They are now connect_vec and concat_vec, which means that they can actually be called.
This is caused by StrVector having a generic implementation for &[S] and so #5898 means that method resolution of ~[~[1]].concat() sees that both StrVector and VectorVector have methods that (superficially) match. They are now connect_vec and concat_vec, which means that they can actually be called.
@indutny is currently working on this. |
@nikomatsakis confirms that, as @Blei said, this is a dup of #3429. Closing |
Rustup r? @ghost changelog: none
With this example:
Option
doesn't implement Iterator, but the following error happens:The text was updated successfully, but these errors were encountered: