You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Specialization: allow some projection when typechecking an impl #32483
<anon>:15:9: 15:12 error: the trait `Bar<u8>` is not implemented for the type `<T as Foo>::TypeB` [E0277]
<anon>:15 impl<T> Foo for T {
The problem seems to be that the type checker is using a projection of TypeB to actually check the impl's definition of TypeB against its bounds. But because it's marked default, the item cannot be projected.
In general, we should loosen up the rules on projections when checking an impl -- but doing so soundly is tricky. It clearly doesn't work to just allow all projections to go through (a la "trans mode"), because in general items could be replaced in more specialized impls. But it does seem reasonable to allow projecting the current item being impled (for any trait ref covered by the impl), because any specialization of that item will be rechecked under its own constraints.
I had the idea of checking the associated type itself rather than normalize(<Self as Trait>::Type) for wf for other reasons.
Maybe just add where-clauses for the projection. We would also have to fix the bug where ambiguous projections result in no normalization (to avoid the associated type variant of #29859).
error[E0277]: the trait bound `<T as Foo>::TypeB: Bar<u8>` is not satisfied
--> src/lib.rs:17:5
|
5 | type TypeB: Bar<Self::TypeA>;
| ----- associated type defined here
...
15 | impl<T> Foo for T {
| ------------------ help: consider further restricting the associated type: `where <T as Foo>::TypeB: Bar<u8>`
| |
| in this `impl` item
16 | type TypeA = u8;
17 | default type TypeB = ImplsBar;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Bar<u8>` is not implemented for `<T as Foo>::TypeB`
Activity
aturon commentedon Mar 25, 2016
cc @nikomatsakis @Kimundi @arielb1
arielb1 commentedon Mar 25, 2016
I had the idea of checking the associated type itself rather than
normalize(<Self as Trait>::Type)for wf for other reasons.Maybe just add where-clauses for the projection. We would also have to fix the bug where ambiguous projections result in no normalization (to avoid the associated type variant of #29859).
oli-obk commentedon Jan 25, 2020
Status: No change, except in diagnostics
Rollup merge of rust-lang#160520 - jackh726:specialization-tests, r=n…
Rollup merge of rust-lang#160520 - jackh726:specialization-tests, r=n…
Rollup merge of rust-lang#160520 - jackh726:specialization-tests, r=n…
Rollup merge of rust-lang#160520 - jackh726:specialization-tests, r=n…
Rollup merge of rust-lang#160520 - jackh726:specialization-tests, r=n…
Unrolled build for #160520
Rollup merge of #160520 - jackh726:specialization-tests, r=nikomatsakis