Regression in 1.94.0 beta: Rustfmt produces broken code for const blocks in array lengths

[theemathas]

Given the following code:

fn foo() {
    let a = [(); const { let x = 1; x }];
}

On version 1.94.0-beta.2 (2026-01-25 23a44d3c70448c08dc6a), rustfmt will format this code into the following code, which is broken:

fn foo() {
    let a = [(); {        onst {        let x = 1;
        x
    }];
}

On version 1.93.0, however, rustfmt correctly formats the code as follows:

fn foo() {
    let a = [(); const {
        let x = 1;
        x
    }];
}

[theemathas]

Additionally, given the following code:

fn foo() {
    let x = [(); const { 1 }];
}

On version 1.93.0, rustfmt does not modify this code. However, on version 1.94.0-beta.2 (2026-01-25 23a44d3c70448c08dc6a), rustfmt will format the code as follows, deleting the const keyword:

fn foo() {
    let x = [(); { 1 }];
}

This seems bad to me, as this will cause churn for users that regularly run rustfmt.

[zachs18]

Seems to have regressed in rust-lang/rust#150519? (same bisect result for both the broken code and the const removal example)

searched nightlies: from nightly-2025-12-05 to nightly-2026-02-03
regressed nightly: nightly-2026-01-03
searched commit range: rust-lang/rust@fcd6309...85c8ff6
regressed commit: rust-lang/rust@a47f4df

bisected with cargo-bisect-rustc v0.6.11

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc -c rustfmt --start 1.93.0 --preserve --prompt --script ./bisect.sh 

bisect.sh:

#!/bin/bash
cp src/lib-orig.rs src/lib.rs
cargo fmt
cat src/lib.rs

[BoxyUwU]

How does one assign themselves to an issue in this repo 😆 I don't seem to have write access to labels/issue state

[ytmimi]

@rustbot claim to assigns yourself to the issue, but I can just assign you.

[ytmimi]

@BoxyUwU I'm not sure if the issue is with rustfmt since the commit the bisection points to doesn't change rustfmt at all, but if changes need to be made to rustfmt they should be made to the rustfmt source in r-l/rust, not this repo.