Skip to content

ICE matching on a non-[u8] const array #66501

Closed
@Nadrieril

Description

@Nadrieril

This produces an ICE (playground link):

fn main() {
    const CONST: &[(); 1] = &[()];
    match &[()] {
        &[()] => {}
        CONST => {}
    }
}

It points to this assert firing:

let data: &[u8] = match (const_val_val, &const_val.ty.kind) {
(ConstValue::ByRef { offset, alloc, .. }, ty::Array(t, n)) => {
assert_eq!(*t, tcx.types.u8);
let n = n.eval_usize(tcx, param_env);
let ptr = Pointer::new(AllocId(0), offset);
alloc.get_bytes(&tcx, ptr, Size::from_bytes(n)).unwrap()
}

This assert assumes that if we match on a &[T; n] with a const, then T must be u8. I'm not sure where this assumption comes from (I'd guess byte-array patterns), but it's clearly wrong. Note that this also fails with any other non-u8 type here instead of ().
Note that this does not fail when the arrays are not behind references, or if we use slices instead of arrays.

EDIT: removed unnecessary slice_patterns feature gate

Metadata

Metadata

Labels

A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)A-slice-patternsArea: Slice patterns, https://github.com/rust-lang/rust/issues/23121C-bugCategory: This is a bug.E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.glacierICE tracked in rust-lang/glacier.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions