Fix ICE in try_to_raw_bytes when array elements have mismatched

[reddevilmidzy]

close: #152683

After #152001, suffixed integer literals preserve their own type during const lowering, so try_to_raw_bytes could call .to_u8() on a scalar with size > 1, causing an ICE. Fix by using try_to_bits(Size::from_bytes(1)).ok() instead.

r? BoxyUwU

[rustbot]

BoxyUwU is currently at their maximum review capacity.
They may take a while to respond.

[reddevilmidzy]

Ah, it seems like the issue is resolved in #152492, but would it be better to revert the change to try_to_raw_bytes and just add the test?

The error changes like this:

#![expect(incomplete_features)]
#![feature(adt_const_params, generic_const_parameter_types, min_generic_const_args)]
fn foo<const N: usize, const A: [u8; N]>() {}

fn main() {
    foo::<_, { [0, 1u8, 2u32, 8u64] }>();
    //~^ ERROR the constant `8` is not of type `u8`
    //~| ERROR the constant `2` is not of type `u8`
}

[BoxyUwU]

Hmm, I would expect it to still be possible to get this ICE somehow even with #152492 🤔 I'm not sure exactly what that would look like though. The underlying problem here remains that we assume nested valtrees are correct for the parent valtree's type.

Even if we check in wfcheck whether this is the case or not diagnostics will still need to handle such illformed valtrees correctly and I expect diagnostics to be calling this function

[BoxyUwU]

Though there's also #152906 which may have interactions here 🤔 Though probably not...

[BoxyUwU]

#![expect(incomplete_features)]
#![feature(adt_const_params, min_generic_const_args)]

struct ArrWrap<const N: [u8; 1]>;

fn main() {
    let _: ArrWrap<{ [1_u8] }>
          = ArrWrap::<{ [1_u16] }>;
}

does this ICE even with #152492?

[BoxyUwU]

@rustbot author

[reddevilmidzy]

#![expect(incomplete_features)]
#![feature(adt_const_params, min_generic_const_args)]

struct ArrWrap<const N: [u8; 1]>;

fn main() {
    let _: ArrWrap<{ [1_u8] }>
          = ArrWrap::<{ [1_u16] }>;
}

does this ICE even with #152492?

#152492 did not cover this case (ICE occurred even when 152492 was applied), and this PR seems to solve it.

[reddevilmidzy]

Hmm, I would expect it to still be possible to get this ICE somehow even with #152492 🤔 I'm not sure exactly what that would look like though. The underlying problem here remains that we assume nested valtrees are correct for the parent valtree's type.

Even if we check in wfcheck whether this is the case or not diagnostics will still need to handle such illformed valtrees correctly and I expect diagnostics to be calling this function

That makes sense, thanks!

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[BoxyUwU]

these checks for tcx.types.u8 are effectively meaningless under mGCA i think.

[BoxyUwU]

can you instead check that the type of the of the element ty::Value is u8 then call to_u8? I expect we don't want to let this function succeed for an array of 1-byte sized ADTs wrapping a u8