-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Specifying associated type requires redundant constraints #39532
Labels
A-typesystem
Area: The type system
C-bug
Category: This is a bug.
E-needs-test
Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
sgrif
added a commit
to diesel-rs/diesel
that referenced
this issue
Feb 4, 2017
The code for transactions is duplicated between SQLite and PostgreSQL. MySQL would have also used identical code. However, the SQL being executed is not universal across all backends. Oracle appears to use the same SQL, but SQL Server has its own special syntax for this. As such, I'm not comfortable promoting this to a default impl on the trait. Instead I've moved the code out into a shared trait/struct, and operate on that instead. I had wanted to make `TransactionManager` be generic over the backend, not the connection itself, since constraints for it will always be about the backend, but I ran into rust-lang/rust#39532 when attempting to do so.
sgrif
added a commit
to diesel-rs/diesel
that referenced
this issue
Feb 4, 2017
The code for transactions is duplicated between SQLite and PostgreSQL. MySQL would have also used identical code. However, the SQL being executed is not universal across all backends. Oracle appears to use the same SQL, but SQL Server has its own special syntax for this. As such, I'm not comfortable promoting this to a default impl on the trait. Instead I've moved the code out into a shared trait/struct, and operate on that instead. I had wanted to make `TransactionManager` be generic over the backend, not the connection itself, since constraints for it will always be about the backend, but I ran into rust-lang/rust#39532 when attempting to do so.
Mark-Simulacrum
added
A-typesystem
Area: The type system
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Jun 23, 2017
Edit: I think I've found the oldest issue about this: #24159 |
Current output:
|
This now compiles. |
estebank
added
the
E-needs-test
Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
label
Feb 2, 2021
jackh726
added a commit
to jackh726/rust
that referenced
this issue
Feb 2, 2021
Add more associated type tests Closes rust-lang#24159 Closes rust-lang#37808 Closes rust-lang#39532 Closes rust-lang#37883 r? `@estebank`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-typesystem
Area: The type system
C-bug
Category: This is a bug.
E-needs-test
Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Reproduction script
Expected behavior: The file compiles successfully
Actual behavior: The function
x
requires 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 1214The text was updated successfully, but these errors were encountered: