| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
suggest adding a where-clause when there is an unmet trait-bound that
can be satisfied if some type can implement it.
|
|
|
|
Because of type inference, duplicate obligations exist and cause duplicate
errors. To avoid this, only display the first error for each (predicate,span).
The inclusion of the span is somewhat bikesheddy, but *is* the more
conservative option (it does not remove some instability, as duplicate
obligations are ignored by `duplicate_set` under some inference conditions).
Fixes #28098
cc #21528 (is it a dupe?)
|
|
|
|
|
|
This improves the error message by telling the user the exact type of
`x` if it doesn't implement `Iterator` in `for ... in x {}`.
Closes #16043.
|
|
This makes edge cases in which the `Iterator` trait was not in scope
and/or `Option` or its variants were not in scope work properly.
This breaks code that looks like:
struct MyStruct { ... }
impl MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
for x in MyStruct { ... } { ... }
Change ad-hoc `next` methods like the above to implementations of the
`Iterator` trait. For example:
impl Iterator<int> for MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
Closes #15392.
[breaking-change]
|
