Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upUnrecognized associated type bound on another associated type #24159
Comments
This comment has been minimized.
This comment has been minimized.
|
This may be related to #23481. |
steveklabnik
added
the
A-associated-items
label
Apr 7, 2015
stevenblenkinsop
referenced this issue
Apr 8, 2015
Closed
ICE: Failed to unify `Obligation(...)` and `ProjectionPredicate(...)` in projection #24204
brson
added
P-medium
I-wrong
labels
Dec 1, 2016
This comment has been minimized.
This comment has been minimized.
|
Edited original post to remove
|
Mark-Simulacrum
added
C-bug
and removed
C-enhancement
I-wrong
labels
Jul 22, 2017
This comment has been minimized.
This comment has been minimized.
|
A lot of related issues for this have been opened over time. Duplicates: #37808, #39532, #40093, #48674, #54375, #54844 Probably same underlying cause: #32722, #37883, #38917, #43475, #47897, #54149 There's also a related discussion on the Rust forums: https://users.rust-lang.org/t/bounds-on-associated-types-enforced-too-soon/12948 |
rkarp
referenced this issue
Dec 10, 2017
Open
Specifying associated type requires redundant constraints #39532
rkarp
referenced this issue
Mar 11, 2018
Open
Traits and associated types are not properly resolved in trait clauses #48674
This comment has been minimized.
This comment has been minimized.
|
Mildly simplified:
So, probably the fix is "just" that we need to do some normalization somewhere or other. My preference is to fix this by moving over to lazy normalization and chalk, which will do away with these sorts of shortcomings for good. But it's probably worth looking to see if this can be fixed a touch more rapidly by adding a normalization in the right place. I'll try to do that in a bit and mentor/open a fix if it seems reasonable. |
rkarp
referenced this issue
May 5, 2018
Open
Associated types bounds seem to be ignored in generic impls #50237
Marwes
referenced this issue
May 10, 2018
Merged
Rewrite all examples to use `impl Parser` instead of `parser!` #156
This comment has been minimized.
This comment has been minimized.
|
Any progress here @nikomatsakis? |
jackmott
referenced this issue
Jul 4, 2018
Open
Possible bug with operator overloading on traits/associated types #52025
This comment has been minimized.
This comment has been minimized.
ZerothLaw
commented
Aug 17, 2018
|
Looks like the issue is known and mentioned at this line: https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/compare_method.rs#L252 This indicates this may be the area to check in when working on this? Still working on understanding a lot of this code, so I'm not sure. |
This comment has been minimized.
This comment has been minimized.
|
Ran into this as well. Here's my minimal test case: trait Bar<T> {}
trait Caz {
type A;
type B: Bar<Self::A>;
}
fn test<T, U>() where T: Caz, U: Caz<A = T::A> {}
|
This was referenced Oct 7, 2018
rkarp
referenced this issue
Oct 14, 2018
Open
Trait bounds on associated types of subtraits don't work correctly #54149
This comment has been minimized.
This comment has been minimized.
elidupree
commented
Mar 26, 2019
|
I've just run into this issue in one of my own projects, and reduced it to a test case that's even simpler than the last one: trait Bar<T> {}
trait Caz {
type A;
type B: Bar<Self::A>;
}
fn test<T: Caz<A = ()>>() {}Although it compiles successfully if you add the bizarrely-tautological-looking For now, I'm stuck with adding the where clause, but that's putting a LOT of boilerplate in my code (the actual where clause is 71 characters long and appears in dozens of places, including being de-facto required in code that uses my library, not just inside the library itself). Is there any progress on this? |
kvark commentedApr 7, 2015
•
edited by Mark-Simulacrum
Gives me:
There is a workaround:
But it's ugly and should not be necessary.
We hit this problem a lot with gfx::Device, and I'd like to see cleaner use of it without explicit
CommandBufferbounds that we use as a workaround.