-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICE: expected int of size 8, but got size 1
#131101
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
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Oct 1, 2024
rustbot
added
the
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
label
Oct 1, 2024
saethlin
removed
the
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
label
Oct 4, 2024
matthiaskrgr
added
the
S-bug-has-test
Status: This bug is tracked inside the repo by a `known-bug` test.
label
Oct 12, 2024
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
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.
auto-reduced (treereduce-rust):
original:
Version information
Command:
/home/matthias/.rustup/toolchains/master/bin/rustc
Program output
The text was updated successfully, but these errors were encountered: