Dispatch MIR pipeline by BodyOwnerKind instead of const context

[lapla-cogito]

fixes #155803

Since e8a4611, hir_body_const_context() returns the parent's const context for a const closure. However inner_optimized_mir() and inner_mir_for_ctfe() were using hir_body_const_context() to decide which MIR pipeline a body goes through. With the new semantics, a const closure nested in a const item gets classified as a constant, so under -Clink-dead-code we either hit "do not use optimized_mir for constants" or steal a body that optimized_mir still needs.

r? oli-obk (since you authored the commit mentioned above, feel free to reroll)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[rustbot]

oli-obk is not on the review rotation at the moment.
They may take a while to respond.

[oli-obk]

Hmmm. We shouldn't ever invoke optimized_mir on const closures defined in const items I think?

Tho I guess with an opaque type as the const's type we could indeed return a const closure. Or just via a const item of fn ptr type?

I'll need to think about this some more, but if you have any thoughts about it lmk. Please add tests for both of these situations, too.

[lapla-cogito]

We shouldn't ever invoke optimized_mir on const closures defined in const items I think?

Is this because const items are only evaluated during CTFE (IIUC)? If so, the examples you mention are counterexamples.

Tho I guess with an opaque type as the const's type we could indeed return a const closure. Or just via a const item of fn ptr type?

I've added a test for the fn ptr type variant, which causes an ICE on current nightly. I also tried opaque-type variants, but they were rejected by unrelated checks before reaching the ICE path 🤔
Therefore, I think there's now a stronger case for invoking optimized_mir on const closures defined inside const items. Thanks.