Remove err methods

[GuillaumeGomez]

To be merged after #42519.

cc @Susurrus@QuietMisdreavus

[rust-highfive]

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

[eddyb]

r? @nikomatsakis

[nikomatsakis]

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.

[nikomatsakis]

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:

letmut 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.

[GuillaumeGomez]

Wo, this example is way better. Great idea!

[nikomatsakis]

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. 

[GuillaumeGomez]

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.

[nikomatsakis]

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!

[GuillaumeGomez]

Now that the previous one has been merged, I just need to make this one works.

[GuillaumeGomez]

Updated.

[nikomatsakis]

tidy check (x86_64-unknown-linux-gnu)
[00:02:00] tidy error: duplicate error code: 619
[00:02:00] tidy error: /checkout/src/librustc_typeck/diagnostics.rs:4668: E0619: r##"
[00:02:00] tidy error: /checkout/src/librustc_typeck/diagnostics.rs:4800: E0619, // intrinsic must be a 

r=me when fixed

[GuillaumeGomez]

@bors: r=nikomatsakis

[bors]

📌 Commit 03eb963 has been approved by nikomatsakis

[GuillaumeGomez]

@bors: r-

[GuillaumeGomez]

@bors: r=nikomatsakis

[bors]

📌 Commit 5acc1de has been approved by nikomatsakis

[bors]

⌛ Testing commit 5acc1de with merge d0e0f53...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing d0e0f53 to master...