Suggest the correct array length on mismatch

[clubby789]

Fixes #107156

I wasn't able to find a way to get the Span for the actual array size unfortunately, so this suggestion can't be applied automatically.

@rustbot label +A-diagnostics

[rustbot]

r? @estebank

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

[clubby789]

Actually, looking at the changes in tests, it might not be best to do this so generally 🤔 . It only really applies when the array is being bound and the type doesn't match. I'm not sure if the information is available here to only lint on those cases.

[compiler-errors]

Hmmm... yeah, I would look at check_decl, but I agree that this help right now does not really add much right now.

@rustbot author
r? @compiler-errors

[clubby789]

Reusing some code from the original array length suggestion mentioned https://github.com/rust-lang/rust/blob/master/compiler/rustc_hir_typeck/src/expr.rs#L1339, this now suggests the correct type for constants. It would be nice to have this also work for let arr: [u8; 2] = [1, 2, 3] which I'll work on

[clubby789]

This now handles let as well as const mismatches.
Some issues:

LL |     let wrong: [u8; 3] = returns_arr();
   |                -------   ^^^^^^^^^^^^^ expected an array with a fixed size of 3 elements, found one with 2 elements
   |                |    |
   |                |    help: consider specifying the actual array length: `2`
   |                expected due to this

'expected due to this' is emitted much further along the line and overlaps which isn't hugely readable, but IDEs should handle it fine which is the requested use case.

for let foo: [u8; 3] = [1, 2], I search for a Local Stmt where there is an initializer with a span matching the error cause, and an explicit type. This does mean that if the initializer is seperate from the let statement it won't work, but it means we don't need to worry about cases like this

    let blah: [u8; 4];
    if true {
        blah = [1];
    } else {
        blah = [3, 4];
    }

(also, I notice that the expected due to this annotation is missing if the let and assignment are seperate.)

@rustbot ready

[compiler-errors]

Hmmm... I guess this is fine. Maybe we should add an ObligationCauseCode for a let with ascribed type so we don't need to do that HIR visiting.

@bors r+

[bors]

📌 Commit 903ca87 has been approved by compiler-errors

It is now in the queue for this repository.