-
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
Remove err methods #42887
Remove err methods #42887
Conversation
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
1b59d3a
to
fc2b380
Compare
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.
Left a few suggestions for the wording. What do you think? My sense is that the extended descriptions are a good place to offer a bit more background information.
src/librustc_typeck/diagnostics.rs
Outdated
Erroneous code example: | ||
|
||
```compile_fail,E0619 | ||
let x; |
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.
This example is simple, but it does conflate an uninitialized value with one where we do not know the type. An alternative might be something like this:
let mut x = vec![];
match x.pop() {
Some(v) => {
// Here, the type of `v` is not (yet) known, so we
// cannot resolve this method call:
v.to_uppercase();
}
None => { }
}
This could be fixed by annotating x
with a type, like x: Vec<String>
. To make it more realistic, we'd need a loop
or something else.
Another example that I encounter a lot:
let vec1 = vec![1, 2, 3];
let vec2 = vec1.iter().map(|x| x * 2).collect();
println!("{}", vec2.len()); // error
with the fix:
let vec1 = vec![1, 2, 3];
let vec2: Vec<_> = vec1.iter().map(|x| x * 2).collect();
println!("{}", vec2.len()); // error
the problem with this one, of course, is that it references the iterator API. But we could probably explain it just by saying that "because collect()
can create many kinds of collections, the type is typically inferred from context." or something like that.
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.
Wo, this example is way better. Great idea!
src/librustc_typeck/diagnostics.rs
Outdated
@@ -4567,6 +4567,52 @@ i_am_a_function(); | |||
``` | |||
"##, | |||
|
|||
E0619: r##" | |||
A not (yet) known type was used. |
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 we could say a bit more here. This message would perhaps be mildly easier to write if we knew what operation was giving it, but anyhow. (As an aside, this is (yet another...) of those messages that would be greatly improved by a "context sensitive" --explain
mechanism, I think).
The type-checker needed to know the type of an expression,
but that type had not yet been inferred. This is most often
fixed by adding a type annotation.
We could go on to give more context, but it may be overkill:
Type inference typically proceeds from the top of the
function to the bottom, figuring out types as it goes.
In some cases -- notably method calls and overloadable
operators like `*` -- the type checker may not have enough
information *yet* to make progress. This can be true even if the
rest of the function provides enough context (because the type-checker
hasn't looked that far ahead yet). In this case, type annotations can be
used to help it along.
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 first sentence isn't supposed to be an explanation, just a short recap of the error. However this explanation could replace the current one since it's (way) more complete.
src/librustc_typeck/diagnostics.rs
Outdated
// as `[usize]` | ||
``` | ||
|
||
In Rust, some types don't have a size at compile-time (like slices and traits |
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 something like this?
In Rust, some types don't have a don't have a known size at compile-time.
For example, in a slice type like [u32]
, the number of elements is not known
at compile-time and hence the overall size cannot be computed. As a result,
such types can only be manipulated through a reference (e.g., &T
or &mut T
)
or other pointer-type (e.g., Box
or Rc
). Try casting to a reference instead:
let x = &[1_usize, 2] as &[usize]; // ok!
Now that the previous one has been merged, I just need to make this one works. |
Updated. |
99a8998
to
c831329
Compare
r=me when fixed |
c831329
to
03eb963
Compare
@bors: r=nikomatsakis |
📌 Commit 03eb963 has been approved by |
@bors: r- |
03eb963
to
5acc1de
Compare
@bors: r=nikomatsakis |
📌 Commit 5acc1de has been approved by |
Remove err methods To be merged after #42519. cc @Susurrus @QuietMisdreavus
☀️ Test successful - status-appveyor, status-travis |
To be merged after #42519.
cc @Susurrus @QuietMisdreavus