Regression: Fail to evaluate self-referential static slices

[nvzqz]

Code

I tried this code:

struct Value {
    values: &'static [&'static Value],
}

static VALUE: Value = Value {
    values: &[&VALUE],
};

I expected to see this happen: compile fine, with the VALUE static containing a slice that references VALUE.

Instead, this happened:

error[E0391]: cycle detected when const-evaluating + checking `VALUE`
 --> src/main.rs:6:13
  |
6 |     values: &[&VALUE],
  |             ^^^^^^^^^
  |
note: ...which requires simplifying constant for the type system `VALUE::promoted[0]`...
 --> src/main.rs:5:1
  |
5 | static VALUE: Value = Value {
  | ^^^^^^^^^^^^^^^^^^^
note: ...which requires const-evaluating + checking `VALUE::promoted[0]`...
 --> src/main.rs:5:1
  |
5 | static VALUE: Value = Value {
  | ^^^^^^^^^^^^^^^^^^^
  = note: ...which again requires const-evaluating + checking `VALUE`, completing the cycle
note: cycle used when linting top-level module
 --> src/main.rs:1:1
  |
1 | / struct Value {
2 | |     values: &'static [&'static Value],
3 | | }
4 | |
... |
8 | |
9 | | fn main() {}
  | |____________^
  = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information

Version it worked on

It most recently worked on: nightly-2024-02-10

Version with regression

nightly-2024-02-11

rustc --version --verbose:

rustc 1.78.0-nightly (6cc484351 2024-02-10)
binary: rustc
commit-hash: 6cc4843512d613f51ec81aba689180c31b0b28b6
commit-date: 2024-02-10
host: aarch64-apple-darwin
release: 1.78.0-nightly
LLVM version: 17.0.6

[DaniPopes]

searched nightlies: from nightly-2024-02-10 to nightly-2024-02-11
regressed nightly: nightly-2024-02-11
searched commit range: d44e3b9...6cc4843
regressed commit: 6cc4843

bisected with cargo-bisect-rustc v0.6.8

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

cargo bisect-rustc -vv --start 2024-02-10 --without-cargo -vv --script rustc -- src/lib.rs 

#119614 cc @RalfJung @oli-obk

[nvzqz]

Context for how I found this: I use this technique in Divan in code generation for benchmarks of generic functions. The simple example I gave is just a minimal reproduction of the issue.

[RalfJung]

Hm, that is very strange. Not sure if there is a good way to get the backtrace of where in the code the cyclic queries are made?

My first guess is that it is the new call to type_of here:

rust/compiler/rustc_const_eval/src/interpret/validity.rs

Lines 464 to 472 in 77f8c3c

	let is_mut =
	matches!(self.ecx.tcx.def_kind(did), DefKind::Static(Mutability::Mut))
	|| !self
	.ecx
	.tcx
	.type_of(did)
	.no_bound_vars()
	.expect("statics should not have generic parameters")
	.is_freeze(*self.ecx.tcx, ty::ParamEnv::reveal_all());

But... surely we can ask for the type of a static while evaluating that very static, that can't be cyclic?

[RalfJung]

Ah no, probably it is related to the fact that we now recursively validate when a constant points to a static. Previously we stopped there. I guess we should not do that for promoteds.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high -E-needs-bisection +T-compiler