-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Bounds on associated types are not taken into account during typeck #26026
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Labels
A-associated-items
Area: Associated items (types, constants & functions)
A-type-system
Area: Type system
C-bug
Category: This is a bug.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
Comments
Rust knows it's right the other way around. It has trouble with carrying over the information for the type equality with This compiles: pub struct Internal<I> {
iter: I
}
impl Internal<()> {
fn new<It: IntoIterator>(iterable: It) -> Internal<It::IntoIter> {
let iter = iterable.into_iter();
Internal { iter: iter }
}
} |
Triage: same issue, slightly different error message today:
|
Centril
added a commit
to Centril/rust
that referenced
this issue
Oct 19, 2019
…asper Use structured suggestion for restricting bounds When a trait bound is not met and restricting a type parameter would make the restriction hold, use a structured suggestion pointing at an appropriate place (type param in param list or `where` clause). Account for opaque parameters where instead of suggesting extending the `where` clause, we suggest appending the new restriction: `fn foo(impl Trait + UnmetTrait)`. Fix rust-lang#64565, fix rust-lang#41817, fix rust-lang#24354, cc rust-lang#26026, cc rust-lang#37808, cc rust-lang#24159, fix rust-lang#37138, fix rust-lang#24354, cc rust-lang#20671.
Centril
added a commit
to Centril/rust
that referenced
this issue
Oct 19, 2019
…asper Use structured suggestion for restricting bounds When a trait bound is not met and restricting a type parameter would make the restriction hold, use a structured suggestion pointing at an appropriate place (type param in param list or `where` clause). Account for opaque parameters where instead of suggesting extending the `where` clause, we suggest appending the new restriction: `fn foo(impl Trait + UnmetTrait)`. Fix rust-lang#64565, fix rust-lang#41817, fix rust-lang#24354, cc rust-lang#26026, cc rust-lang#37808, cc rust-lang#24159, fix rust-lang#37138, fix rust-lang#24354, cc rust-lang#20671.
The report now correctly type-checks. |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Labels
A-associated-items
Area: Associated items (types, constants & functions)
A-type-system
Area: Type system
C-bug
Category: This is a bug.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
Note that this is the current definition of IntoIterator:
So we try to make a type that can be instantiated with any IntoIter, storing its Iterator:
Completely nonsensical. Nothing is asking I to be an Iterator, except for IntoIterator's own definiton, which proves that it is in fact an Iterator. But ok, let's try to assert that it is:
Again nothing is demanding this by IntoIterator, which is already proving it. This works, though:
Which shouldn't be necessary.
The text was updated successfully, but these errors were encountered: