ICE: expected int of size 8, but got size 1
#126359
Labels
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
S-bug-has-test
Status: This bug is tracked inside the repo by a `known-bug` test.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
matthiaskrgr
added
I-ICE
rustbot
added
the
needs-triage
|
Another tainting issue -- the array is ill-typed, we shouldn't look at its details: Cc @oli-obk |
|
Looking it into it a little bit the problem is that match relation.relate(sz_a, sz_b) {
Ok(sz) => Ok(Ty::new_array_with_const_len(tcx, t, sz)),
Err(err) => {
// Check whether the lengths are both concrete/known values,
// but are unequal, for better diagnostics.
let sz_a = sz_a.try_to_target_usize(tcx);
let sz_b = sz_b.try_to_target_usize(tcx);
match (sz_a, sz_b) {
(Some(sz_a_val), Some(sz_b_val)) if sz_a_val != sz_b_val => Err(
TypeError::FixedArraySize(ExpectedFound::new(true, sz_a_val, sz_b_val)),
),
_ => Err(err),
}
}
} |
|
FWIW the diagnostic previously shown also looked odd |
|
I think we would have had a valtree for |
matthiaskrgr
added
the
S-bug-has-test
saethlin
removed
the
needs-triage
jhpratt
added a commit
to jhpratt/rust
that referenced
this issue
Nov 26, 2024
…, 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 rust-lang#126359
Fixes rust-lang#131101
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Nov 27, 2024
Rollup merge of rust-lang#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 rust-lang#126359 Fixes rust-lang#131101
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
auto-reduced (treereduce-rust):
original:
Version information
Command:
/home/matthias/.rustup/toolchains/master/bin/rustcProgram output
The text was updated successfully, but these errors were encountered: