-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Implement special-cased projection error message for some common traits #98863
Conversation
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
☔ The latest upstream changes (presumably #98482) made this pull request unmergeable. Please resolve the merge conflicts. |
98197f5
to
a1dcb95
Compare
)) | ||
} else if Some(trait_def_id) == self.tcx.get_diagnostic_item(sym::Iterator) { | ||
Some(format!( | ||
"expected `{self_ty}` to be an iterator of `{expected_ty}`, but it actually returns items of `{normalized_ty}`" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm less enthusiastic about the wording "expected foo
to be an iterator of i32
but it actually returns items of u32
", because it feels we're mixing up concepts here. We could use "yields items of u32
" instead, but yield
isn't a keyword people will know from Rust (yet).
What about "expected foo
to be an iterator over items of type i32
but it is an iterator over items of type u32
"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "yield" is okay here since it doesn't necessarily imply connection to the yield
kw, but I can just use "over".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of
expected `foo` to be an iterator that yields `i32` but it yields `u32`
)) | ||
} else if Some(trait_def_id) == self.tcx.lang_items().future_trait() { | ||
Some(format!( | ||
"expected `{self_ty}` to be a future that yields `{expected_ty}`, but it actually yields `{normalized_ty}`" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the same about using "yields" to talk about the Future::Output
? What about "...to be a future that resolves to ty
, but it resolves to ty
".
Let's also drop the "actually". It doesn't add as much to the messaging, I feel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code changes look good, I have some qualms over wording. What do you think?
(Apologies for the review delay)
I can apply these messaging changes, the ones I wrote originally were just kinda there to demonstrate the concept. @rustbot author |
a1dcb95
to
3fdf3cb
Compare
@rustbot ready Adjusted the wording, what do you think now? Open to more changes if needed. |
@@ -22,19 +22,22 @@ LL | where | |||
LL | F: for<'r> T0<'r, (<Self as Ty<'r>>::V,), O = <B as Ty<'r>>::V>, | |||
| ^^^^^^^^^^^^^^^^^^^^ required by this bound in `T1::m` | |||
|
|||
error[E0271]: type mismatch resolving `for<'r> <[closure@$DIR/issue-62203-hrtb-ice.rs:42:17: 42:20] as FnOnce<((&'r u8,),)>>::Output == Unit3` | |||
error[E0271]: expected `[closure@$DIR/issue-62203-hrtb-ice.rs:42:16: 42:19]` to be a closure that returns `Unit3`, but it returns `Unit4` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not for this PR: I would love to instead say "expected the closure to return Unit3
..." and have a span label pointing at the closure, but we need to improve that in general.
@@ -1,7 +1,7 @@ | |||
error[E0271]: type mismatch resolving `<fn() -> impl Sized {hi} as FnOnce<()>>::Output == Box<u8>` | |||
--> $DIR/issue-98608.rs:4:39 | |||
error[E0271]: expected `fn() -> impl Sized {hi}` to be a fn item that returns `Box<u8>`, but it returns `impl Sized` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly here, we could refer to the function by name
expected `hi` to return `Box<u8>`, but it returns `impl Sized`
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (f03ce30): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesThis benchmark run did not return any relevant results for this metric. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
Not sure what the best phrasing is, but I feel like these are more clear than the plain
<Type as Iterator>::Output == Type
messages.If this is actually a good idea, are there any other traits this could benefit?