Stall computing instance for drop shim until it has no unsubstituted const params by compiler-errors · Pull Request #127068 · rust-lang/rust (original) (raw)
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):
| self.place_ty(place).needs_drop(self.tcx(), self.elaborator.param_env()) |
|---|
However, since we don't keep the param-env of the instance we resolved the item for, we use the wrong param-env:
| let param_env = tcx.param_env_reveal_all_normalized(def_id); |
|---|
(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 #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).