Fix ICE: Don't try to evaluate type_consts when eagerly collecting items

[Keith-Cancel]

This fixes #151246

The change is pretty straightforward if the Monomorphization strategy is eager which -Clink-dead-code=true sets. This then would lead to the existing code to try and evaluate a type const which does not have a body to evaluate leading to an ICE. The change is pretty straight forward just skip over type consts.

This also seems like a sensible choice to me since a MonoItem can only be a Fn, Static, or Asm. A type const is none of the aforementioned.

And even if it was added to the MonoItems list it would then later fail this check:

rust/compiler/rustc_monomorphize/src/collector.rs

Lines 438 to 440 in fe98ddc

	let DefKind::Static { nested, .. } = tcx.def_kind(def_id) else { bug!() };
	// Nested statics have no type.

Since that explicitly checks that the MonoItem's DefKind is static and not anything else.

One more change is the addition of a simple test of the example code from #151246 that checks that code compiles successfully with -Clink-dead-code=true.

The only other change was to make the guard checks a little easier to read by making the logic more linear instead of one big if statement.

r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args

[BoxyUwU]

can you add a multi-crate test such as:

// crate a
#[type_const]
pub const FOO: usize = 1;

// crate b
fn main() {
    println!("{}", a::FOO);
}

[BoxyUwU]

though that might ICE until #151260 is merged? unsure what the overlap here is

[Keith-Cancel]

I did not really see any overlap, you might want to ask @reddevilmidzy about that, but yea such a test would currently ICE. Might be better to make that part of #151260?

[Keith-Cancel]

@BoxyUwU was there anything other than that FIXME comment for future investigation?

[BoxyUwU]

@bors r+ rollup

[rust-bors]

📌 Commit 7635702 has been approved by BoxyUwU

It is now in the queue for this repository.