-
-
Notifications
You must be signed in to change notification settings - Fork 15k
Specifying associated type requires redundant constraints #39532
Copy link
Copy link
Closed
Labels
A-type-systemArea: Type systemArea: Type systemC-bugCategory: This is a bug.Category: This is a bug.E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.Call for participation: An issue has been fixed and does not reproduce, but no test has been added.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-type-systemArea: Type systemArea: Type systemC-bugCategory: This is a bug.Category: This is a bug.E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.Call for participation: An issue has been fixed and does not reproduce, but no test has been added.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Reproduction script
Expected behavior: The file compiles successfully
Actual behavior: The function
xrequires an additional<T as Foo>::Baz: Bar<U>. This check is entirely redundant with the trait definition, and would always have to be true forT: Foo<Bar=U>to hold.This only occurs if the constraint referencing the first associated type is a parameter to the trait, not an associated type, which is why this doesn't happen for
IntoIterator. This appears to have been an unintended side effect of RFC 1214