Rollup merge of #133367 - compiler-errors:array-len-mismatch, r=BoxyUwU

Simplify array length mismatch error reporting (to not try to turn consts into target usizes)

This changes `TypeError::FixedArrayLen` to use `ExpectedFound<ty::Const<'tcx>>` (instead of `ExpectedFound<u64>`), and renames it to `TypeError::ArrayLen`. This allows us to avoid a `try_to_target_usize` call in the type relation, which ICEs when we have a scalar of the wrong bit length (i.e. u8).

This also makes `structurally_relate_tys` to always use this type error kind any time we have a const mismatch resulting from relating the array-len part of `[T; N]`.

This has the effect of changing the error message we issue for array length mismatches involving non-valtree consts. I actually quite like the change, though, since before:

```
LL | fn test<const N: usize, const M: usize>() -> [u8; M] {
   |                                              ------- expected `[u8; M]` because of return type
LL |     [0; N]
   |     ^^^^^^ expected `M`, found `N`
   |
   = note: expected array `[u8; M]`
              found array `[u8; N]`
```

and after, which I think is far less verbose:

```
LL | fn test<const N: usize, const M: usize>() -> [u8; M] {
   |                                              ------- expected `[u8; M]` because of return type
LL |     [0; N]
   |     ^^^^^^ expected an array with a size of M, found one with a size of N
```

The only questions I have are:
1. Should we do something about backticks here? Right now we don't backtick either fully evaluated consts like `2`, or rigid consts like `Foo::BAR`.... but maybe we should? It seems kinda verbose to do for numbers -- maybe we could intercept those specifically.
2. I guess we may still run the risk of leaking unevaluated consts into error reporting like `2 + 1`...?

r? ``@BoxyUwU``

Fixes #126359
Fixes #131101

0 files changed, 0 insertions, 0 deletions