check if len of array const arg matches the expected len of the type when lowering to valtree

[sjwang05]

When creating valtrees for arrays passed as const args in lower_const_arg_array, we assume the array has the correct length without actually checking the length of the arg, leading to UB at runtime (#155168) or an ICE during CTFE (#151079). This PR adds a check comparing the expected length of the type with the actual number of elements, similar to lower_const_arg_tup.

fixes #155168

[rustbot]

HIR ty lowering was modified

cc @fmease

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 17 candidates

[JohnTitor]

IMO it should catch more cases if len is normalized, e.g. type const LEN (I haven't checked deeply so it may be caught by somewhere already)

View changes since the review

[sjwang05]

Thanks, I changed it to call try_normalize_erasing_regions with an empty ParamEnv on the expected len and added a test for it, so now something like fn baz<const A: [u8; <S as Trait>::LEN]>() {} produces the correct error. Something like fn baz<T: Trait, const A: [u8; <T as Trait>::LEN]>() {} still ICEs if too long/produces UB if too short, however, since we can't resolve T to an actual type: trying to do try_evaluate_const with a non-empty ParamEnv led to cycle errors.

[JohnTitor]

Could you open another issue and add an ICE test for that case (if not exists yet)? At least we should track it.