GCI: Don't try to eval / collect mono items inside overly generic free const items

[fmease]

Fixes #136156. Thanks for the pointers, errs!

There's one (preexisting) thing of note (maybe?). There's a difference between const _: () = panic!(); and const _<'a>: () = panic!();: The former is a pre-mono error, the latter is a post-mono error. For comparison, both fn _f() { const { panic!() } } and fn _f<'a: 'a>() { const { panic!() } } are post-mono errors.

cc @oli-obk
r? compiler-errors or reassign

[compiler-errors]

r=me when green

There's a difference between const _: () = panic!(); and const _<'a>: () = panic!();: The former is a pre-mono error, the latter is a post-mono error.

This seems inconsistent, and pretty bad. But luckily something we can change before stabilizing generic consts :)

I think we should probably change the code introduced in #121387 to instead call requires_monomorphization instead of is_empty on the generics.

It should also preferably check for impossible predicates in the same way we do for -Clink-dead-code/-Zcollect-mono-items=eager, since we must avoid monomorphizing consts with impossible (possibly trivial) preds. You could probably turn that into an ICE today.

You can feel free to do this in a separate PR, since it may cause some perf changes. Maybe open a follow-up issue for this?

[fmease]

@bors r=compiler-errors

[bors]

📌 Commit 0a9ee02 has been approved by compiler-errors

It is now in the queue for this repository.