Fix expected/found order on impl trait projection mismatch error #80828
Conversation
|
(rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
| &msg, | ||
| proj_ty, | ||
| values.expected, | ||
| ) || self.suggest_constraint( |
There was a problem hiding this comment.
I added this to avoid losing a helpful suggestion in the impl-trait-return-missing-constraint test.
I wonder how much else of the expected_projection function makes sense to run in this case (when the projection type is found) as well.
| = note: expected struct `Box<(dyn for<'r> Fn(&'r (dyn ToString + 'r)) -> impl Debug + 'static)>` | ||
| found struct `Box<(dyn for<'r> Fn(&'r (dyn ToString + 'r)) -> Option<String> + 'static)>` | ||
| = note: expected struct `Box<(dyn for<'r> Fn(&'r (dyn ToString + 'r)) -> Option<String> + 'static)>` | ||
| found struct `Box<(dyn for<'r> Fn(&'r (dyn ToString + 'r)) -> impl Debug + 'static)>` |
There was a problem hiding this comment.
This change looks like it might be wrong to me. On the other hand I'm not sure why this test doesn't compile. Bar's Iterator impl defines its Item to be FooItem, but the compiler complains Bar doesn't satisfy impl Iterator<Item = FooItem> because the Item type is wrong? It seems the compiler is being inconsistent about whether ham gets to see the true type of FooRet, or something.
At any rate this test is a complicated setup involving a nightly feature, so I don't think it's a big problem if this pr worsens the diagnostic in such a case.
JohnCSimon
added
S-waiting-on-review
|
☔ The latest upstream changes (presumably #80843) made this pull request unmergeable. Please resolve the merge conflicts. |
SNCPlay42
force-pushed
the
opaque-projections
branch
from
b88e06c to
4db7308
Compare
|
☔ The latest upstream changes (presumably #78052) made this pull request unmergeable. Please resolve the merge conflicts. |
SNCPlay42
force-pushed
the
opaque-projections
branch
from
4db7308 to
30e67a5
Compare
|
☔ The latest upstream changes (presumably #82263) made this pull request unmergeable. Please resolve the merge conflicts. |
SNCPlay42
force-pushed
the
opaque-projections
branch
from
30e67a5 to
d666f6e
Compare
JohnCSimon
added
S-waiting-on-review
|
☔ The latest upstream changes (presumably #82898) made this pull request unmergeable. Please resolve the merge conflicts. |
SNCPlay42
force-pushed
the
opaque-projections
branch
from
d666f6e to
525e23a
Compare
bstrie
added
S-waiting-on-review
|
r? @estebank as per GitHub suggestions |
|
@bors r+ |
|
📌 Commit 525e23a has been approved by |
bors
added
S-waiting-on-bors
…ebank Fix expected/found order on impl trait projection mismatch error fixes rust-lang#68561 This PR adds a new `ObligationCauseCode` used when checking the concrete type of an impl trait satisfies its bounds, and checks for that cause code in the existing test to see if a projection's normalized type should be the "expected" or "found" type. The second commit adds a `peel_derives` to that test, which appears to be necessary in some cases (see projection-mismatch-in-impl-where-clause.rs, which would still give expected/found in the wrong order otherwise). This caused some other changes in diagnostics not involving impl trait, but they look correct to me.
|
☀️ Test successful - checks-actions |
fixes #68561
This PR adds a new
ObligationCauseCodeused when checking the concrete type of an impl trait satisfies its bounds, and checks for that cause code in the existing test to see if a projection's normalized type should be the "expected" or "found" type.The second commit adds a
peel_derivesto that test, which appears to be necessary in some cases (see projection-mismatch-in-impl-where-clause.rs, which would still give expected/found in the wrong order otherwise). This caused some other changes in diagnostics not involving impl trait, but they look correct to me.