const eval interpreter step limit being hit on nightly for long-running while loop

[pnkfelix]

I tried this code (playpen):

const _DUMMY: u8 = {
    let mut data = [0; 131072];
    let mut idx = 0;
    while idx < data.len() {
        data[idx] = idx as u8;
        idx += 1;
    }
    5
};

#[test]
fn check() { }

I expected to see this happen: Code compiles, test runs and passes.

Instead, this happened: Code fails to compile, due to:

error[[E0080]](https://doc.rust-lang.org/nightly/error-index.html#E0080): evaluation of constant value failed
 --> src/lib.rs:6:9
  |
6 |         idx += 1;
  |         ^^^^^^^^ exceeded interpreter step limit (see `#[const_eval_limit]`)

For more information about this error, try `rustc --explain E0080`.

It does not occur on stable or beta.

(To be clear: I suspect this might be a const-eval implementation artifact that we cannot readily address. But we may need to figure out how to give better guidance, since the current diagnostic is telling people to muck with an attribute that is not available without opting into a feature gate.)

Meta

rustc --version --verbose:

Nightly channel

Build using the Nightly version: 1.67.0-nightly

(2022-10-30 77e57db384aca99444c3)

[pnkfelix]

cc #67217

[pnkfelix]

See also discussion in #93481

(if there are other issues filed for this regression, or if there's a precedent for not filing such issues for this particular regression, then my apologies. I searched and couldn't find evidence to not file it.)

[tedinski]

This apparently affects nightly-2022-10-25 but not nightly-2022-10-24

[celinval]

BTW, we started seeing this issue on nightly-2022-10-25. This test works fine on +nightly-2022-10-24

[camshaft]

I was able to workaround this issue by replacing data.len() with DATA_LEN

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=4196b2135bd3c14f250f33ec5f160627

[saethlin]

I dropped the length of data to 120000 so that this runs on both sides of the regression. Doing the most naive benchmarking I measure a ~11% slowdown in cargo clean && cargo check --tests and a ~16% slowdown in cargo miri test.

How did this get past the compiler perf monitoring? Surely we didn't merge a PR in that time window that regressed one of the secondary benchmarks by 11%, right? Is this some workload that's just very different from ctfe-stress?

[apiraino]

WG-prioritization assigning priority (Zulip discussion) (also to stimulate a wider T-compiler discussion about it)

@rustbot label -I-prioritize +P-high

[apiraino]

visiting during T-compiler meeting on Zulip: followup discussion on this Zulip stream

@rustbot label -I-compiler-nominated