const_allocate intrinsic: what should it do at runtime?

[RalfJung]

We have a const_allocate intrinsic to perform heap allocations during CTFE. It should not be called during runtime, but we do have to generate some code for that case. Currently, we make it return NULL.

I think calling this at runtime is always an error, so we shouldn't just silently continue execution. We should either panic or abort. (The codegen backend already knows how to do both of these things, so this should not be very hard to implement.)

@rust-lang/wg-const-eval what do you think?

[oli-obk]

Seems reasonable. I am still hoping we can just not generate code for these intrinsics at all, but considering the extra effort that requires, we can just turn them into aborts and thus force everyone to use const_eval_select and handle the runtime case explicitly.

[oli-obk]

Maybe i'll just take this opportunity and implement #93145 instead, so backends just get MIR instead of having to hand-roll some logic for each backend

[RalfJung]

We already have a MIR pass that lowers some intrinsics away, you might just add these there.

[oli-obk]

That happens for CTFE MIR, too, so that's not ideal 😆. We'd need an additional pass just for optimized mir.

[fee1-dead]

That happens for CTFE MIR, too, so that's not ideal 😆. We'd need an additional pass just for optimized mir.

I think we should do this. const_eval_select would work in a MIR pass as well.

[oli-obk]

After #148820 we could just ICE in the optimized MIR query for comptime fns