Rollup merge of #127068 - compiler-errors:stall-drop, r=BoxyUwU

Stall computing instance for drop shim until it has no unsubstituted const params

Do not inline the drop shim for types that still have unsubstituted const params.

## Why?

#127030 ICEs because it tries to inline the drop shim for a type with an unsubstituted const param. In order to generate this shim, this requires calling the drop shim builder, which invokes the trait solver to compute whether constituent types need drop (since we compute if a type is copy to disqualify any `Drop` behavior):

https://github.com/rust-lang/rust/blob/9c3bc805dd9cb84019c124b9a50fdff1e62a7ec9/compiler/rustc_mir_dataflow/src/elaborate_drops.rs#L378

However, since we don't keep the param-env of the instance we resolved the item for, we use the wrong param-env:
https://github.com/rust-lang/rust/blob/9c3bc805dd9cb84019c124b9a50fdff1e62a7ec9/compiler/rustc_mir_transform/src/shim.rs#L278
(which is the param-env of `std::ptr::drop_in_place`)

This param-env is notably missing `ConstParamHasTy` predicates, and since we removed the type from consts in https://github.com/rust-lang/rust/pull/125958, we literally cannot prove these predicates in this (relatively) empty param-env. This currently happens in places like the MIR inliner, but may happen elsewhere such as in lints that resolve terminators.

## What?

We force the inliner to not consider calls for `drop_in_place` for types that have unsubstituted const params.

## So what?

This may negatively affect MIR inlining, but I doubt this matters in practice, and fixes a beta regression, so let's fix it. I will look into approaches for fixing this in a more maintainable way, perhaps delaying the creation of drop shim bodies until codegen (like how intrinsics work).

0 files changed, 0 insertions, 0 deletions