-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Bounds on associated types are not taken into account during typeck #26026
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
Gankra
added
A-type-system
Area: Type system
A-associated-items
Area: Associated items (types, constants & functions)
I-papercut
labels
Jun 5, 2015
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:
|
Mark-Simulacrum
changed the title
Type checker drops the ball with IntoIterator
Bounds on associated types are not taken into account during typeck
May 16, 2017
jonas-schievink
added
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.
labels
Jun 13, 2019
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. |
fmease
added
A-type-system
Area: Type system
and removed
A-type-system
Area: Type system
labels
Dec 21, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in 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: