Expected u32 found usize error on array/slice gives unhelpful help text

[KallDrexx]

fn main() {
    let array = [1, 2, 3];
    test(array.len());
}

fn test(length: u32) {
    println!("{}", length);
}

Gives the following compile time error on rustc 1.22.1 (stable):

Compiling playground v0.0.1 (file:///playground)
error[E0308]: mismatched types
 --> src/main.rs:3:10
  |
3 |     test(array.len());
  |          ^^^^^^^^^^^ expected u32, found usize
  |
  = help: here are some functions which might fulfill your needs:
          - .count_ones()
          - .count_zeros()
          - .leading_zeros()
          - .trailing_zeros()

error: aborting due to previous error

error: Could not compile `playground`.

I'm assuming there's a lot of nuance in the engine that gives suggestion so I don't know how I would personally codify the rules (and even if casting as a u32 is always appropriate since I guess it could overflow) but I do know that the suggestions definitely do not point me in the right direction.

[estebank]

I believe the output for type errors where the expected and found types are numeric should be:

error[E0308]: mismatched types
 --> src/main.rs:3:10
  |
3 |     test(array.len());
  |          ^^^^^^^^^^^ expected u32, found usize
  |
  = help: you can cast an `usize` to `u32`:
  |
3 |     test(array.len() as u32);
  |          ^^^^^^^^^^^^^^^^^^
  = note: if the value doesn't fit it will be truncated when casting from `usize` to `u32`

The last note should be one of the following caveats as appropriate depending on the types:

• Casting from a larger integer to a smaller integer (e.g. u32 -> u8) will truncate
• Casting from a smaller integer to a larger integer (e.g. u8 -> u32) will
  • zero-extend if the source is unsigned
  • sign-extend if the source is signed
• Casting from a float to an integer will round the float towards zero
  • NOTE: currently this will cause Undefined Behavior if the rounded value cannot be represented by the target integer type. This includes Inf and NaN. This is a bug and will be fixed.
• Casting from an integer to float will produce the floating point representation of the integer, rounded if necessary (rounding strategy unspecified)
• Casting from an f32 to an f64 is perfect and lossless
• Casting from an f64 to an f32 will produce the closest possible value (rounding strategy unspecified)
  • NOTE: currently this will cause Undefined Behavior if the value is finite but larger or smaller than the largest or smallest finite value representable by f32. This is a bug and will be fixed.

---

The checks can be added to check_ref (modifying it to take &mut err so that multiple notes/labels can be added) or in the else clause before suggesting methods.

[estebank]

@leonardo-m, @nikomatsakis what would be the appropriate suggestion in this case?

[leonardo-m]

The proposed messages seem OK to me.

More generally I think that using naked "as" casts for narrowing is the wrong default to use in Rust. You can't have a nicely designed language that performs overflow tests in debug mode and at the same time encourage the use of "as". In my code I use a to!{} macro that shows the default behaviour that Rust missed to use (I'll try to push for this change in the next Epoch):

#![cfg_attr(debug_assertions, feature(try_from))]

#[cfg(debug_assertions)]
use std::convert::TryFrom;

#[cfg(not(debug_assertions))]
macro_rules! to { ($e:expr, $t:ident) => (($e) as $t)  }

#[cfg(debug_assertions)]
macro_rules! to { ($e:expr, $t:ident) => ($t::try_from($e).unwrap())  }

(Recently the situation is improving for FP<->Int conversions with -Zsaturating-float-casts that should become the default).

[nikomatsakis]

I agree that as is bad, but we've never settled on a "nice" replacement, right? I wish that we had methods like to_u32() or something... (why don't we, anyway?).

Anyway, the messages seem ok.

[GuillaumeGomez]

It's part of a more global suggestion engine that is quite "simple" (aka stupid) I wrote a few months ago. Maybe we should start thinking about it and how we could improve depending on the situation?

[KallDrexx]

FWIW, as someone who used rust a year+ ago before stopping and only just now picking it up 95% of the times the suggestion engine works great and has done a good job on pointing me in the right direction. It was only this scenario that stuck out to me.

[estebank]

On nightly the compiler now only complains about the type mismatch, without any hints as to casting:

error[E0308]: mismatched types
 --> src/main.rs:3:10
  |
3 |     test(array.len());
  |          ^^^^^^^^^^^ expected u32, found usize

The compiler will suggest now if the conversion is lossless to use .into() (modulo the bug I just saw where it the suggestion doesn't add parenthesis around a cast).

---

The compiler could suggest using a cast when dealing with usize/isize, as I don't think there's any other sane way to deal with conversions from/to them, am I wrong?