ICE in clippy::borrow_interior_mutable_const

[saethlin]

Summary

#![deny(clippy::borrow_interior_mutable_const)]

use std::cell::UnsafeCell;

const ATOMIC_TUPLE: (Vec<UnsafeCell<u8>>, u8) = (Vec::new(), 42);

fn main() {
    let _x = &ATOMIC_TUPLE.0;
}

reports:

error: internal compiler error: /home/ben/rust/compiler/rustc_middle/src/ty/consts/valtree.rs:55:18: expected branch, got Leaf(0x0000000000000000)

thread 'rustc' panicked at /home/ben/rust/compiler/rustc_middle/src/ty/consts/valtree.rs:55:18:

The problem is this unwrap_branch: https://github.com/rust-lang/rust-clippy/blob/0ce07f61db8c9de51e6ecd38aa62eb3145417c0f/clippy_lints/src/non_copy_const.rs#L222-L223

Version

rustc 1.81.0-nightly (c1b336cb6 2024-06-21)
binary: rustc
commit-hash: c1b336cb6b491b3be02cd821774f03af4992f413
commit-date: 2024-06-21
host: x86_64-unknown-linux-gnu
release: 1.81.0-nightly
LLVM version: 18.1.7

Figuring out what's broken here is blocking https://github.com/rust-lang/rust/pull/126793

[y21]

Looks like the lint calls is_value_unfrozen_expr with the type of ATOMIC_TUPLE.0 (Vec<UnsafeCell<i32>>), but it is passing the valtree of the whole const (a tuple), so the type does not match the valtree, however they need to match each other so that the function can correctly traverse the valtree. Otherwise we run into this ICE here where the function thinks it's looking at struct Cap(usize); and expecting a branch but it's already at the usize which is a leaf.

That specific repro seems to only ICE in nightly, probably because of #12691 where the lint was made stronger, but the root cause has existed for longer it seems. Smaller repro that also ICEs on stable:

use std::cell::Cell;

const C: ((i32, Cell<i32>), i32) = ((0, Cell::new(1)), 2);

fn main() {
  let _x = &C.0;
}

[J-ZhengLi]

Is there any workaround? I tried allowing the lint but the code still causing ICE

[blyxyas]

I have a working patch that would make this ICE into a FN (It should lint, right?), which is preferable.

[J-ZhengLi]

The repro provided by OP still has FN (although the one coming from @y21 got fixed), should we reopen this?

[Jarcho]

Why is this a FN? The constant doesn't actually contain any interior mutability which means the borrow can't mutate anything.

[J-ZhengLi]

Why is this a FN? The constant doesn't actually contain any interior mutability which means the borrow can't mutate anything.

Ahh, right....