-
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
Confusing error when summing iterator of ()
#105184
Comments
@jvns out of curiosity, what dev environment were you using? Was it the playground, VSCode, IntelliJ or running The output from the terminal gives a little extra context that helps to piece together some of the bullet points (the last note), but of course I'd like to add a bit more context than we have today:
|
Could this look like
or
Ideally this would say "...cannot be summarized from...", but "summarized" has been too far separated from "sum" in English.1 I don't really like having "an iterator over" in either of these but I'd either include it for consistency, or remove it from both. Also don't forget Footnotes
|
I'd use "summed" rather than "summarized" in this context |
The problem with "summed" is that it is a thing you do to the individual items and not a thing you do to the result. You can say "I summed two numbers" but you can't say "I summed the answer". The latter suggests you added the answer to something else, not that you added things to get the answer. |
I was using I don't see this part of the error message though:
this seems much clearer to me:
|
I think we can make this a |
I have the following output:
Along with @aDotInTheVoid's change the output would be:
I'm exploring how I can make the "the following impls" note less verbose. |
…lemented, r=estebank Add `rustc_on_unimplemented` to `Sum` and `Product` trait. Helps with rust-lang#105184, but I don't think it fully fixes it.
…lemented, r=estebank Add `rustc_on_unimplemented` to `Sum` and `Product` trait. Helps with rust-lang#105184, but I don't think it fully fixes it.
Point out the type of associated types in every method call of iterator chains Partially address rust-lang#105184 by pointing out the type of associated types in every method call of iterator chains: ``` note: the expression is of type `Map<std::slice::Iter<'_, {integer}>, [closure@src/test/ui/iterators/invalid-iterator-chain.rs:12:18: 12:21]>` --> src/test/ui/iterators/invalid-iterator-chain.rs:12:14 | 10 | vec![0, 1] | ---------- this expression has type `Vec<{integer}>` 11 | .iter() | ------ associated type `std::iter::Iterator::Item` is `&{integer}` here 12 | .map(|x| { x; }) | ^^^^^^^^^^^^^^^ associated type `std::iter::Iterator::Item` is `()` here ``` We also reduce the number of impls we mention when any of the candidates is an "exact match". This benefits the output of cases with numerics greatly. Outstanding work would be to provide a structured suggestion for appropriate changes, like in this case detecting the spurious `;` in the closure.
Given the current output, I believe the only outstanding work is to look at the involved closures and point at stray
|
Current output:
|
Here's some code (playground):
This has an obvious bug: You can't sum a bunch of
()
and get ani32
as a result. Here's the error message, though:This was very confusing to me -- I'd expect to see an error saying something like
Sum
not implemented forIter<()>
. But instead it says thatSum
is not implemented for i32 But I'm not trying to sum i32s!(my actual bug was actually that I'd accidentally added an extra
;
in my code, so that I was trying to sum()
s instead ofi32
, and the confusing error message made it harder to figure out that out)What's actually going on here is:
i32
has a static method calledsum(iter: Iter<i32>)
, that comes from theSum
trait.Iter
has asum()
method that calls this static method oni32
my_iter.sum()
, it tries to calli32::sum(my_iter)
i32::sum
isn't defined forIter<()>
the trait
Sum<&()>is not implemented for
i32``I might not have gotten all the types/terms exactly right, but I think that's the gist of it.
This all makes sense, but it's was pretty confusing for me to unwind. Maybe the compiler could have helped me unwind it?
reporting as requested by @estebank
The text was updated successfully, but these errors were encountered: