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.

[oli-obk]

I did some digging in the compiler, and I think the right solution is to treat all const closures as ConstContext::ConstFn regardless of their body. My rationale is as follows:

1. you can return a const closure from a const item
2. then you can invoke it at runtime
3. if the const closure calls const-only code (not merged yet Add very basic "comptime" fn implementation #148820) then that would "work" when the const closure is defined in a const item
4. but when called at runtime, there is no code to call, likely leading to an ICE in the future when fetching optimized_mir for a function that doesn't have runtime logic and thus no optimized_mir

[rust-bors]

☔ The latest upstream changes (presumably #156078) made this pull request unmergeable. Please resolve the merge conflicts.