Tracking Issue for infallible promotion

[RalfJung]

This is a tracking issue for the RFC "3027" (rust-lang/rfcs#3027).
The RFC does not have a feature gate.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC
• Adjust documentation (see instructions on rustc-dev-guide)

Unresolved Questions

• What should we do about promoting const fn calls in const/static initializers? See this crater analysis and this Zulip thread.

Implementation history

• stop promoting union field accesses in 'const' #77526
• remove this weird special case from promotion #78363
• avoid promoting division, modulo and indexing operations that could fail #80579

[RalfJung]

In #80243 we learned that there is at least some code (e.g. rodrimati1992/abi_stable_crates#46) that relies in non-trivial ways on const fn calls being promoted in a const/static initializer. We need to figure out how to move forward with such code. I see these options:

• Live with the fact that promoteds in const/static initializers can fail even if they are not required for said initializer. This means no breaking change here, but it will require care in MIR optimizations, MIR printing, maybe more.
• Make sure that all potentally-failing promoteds in const/static initializers are required to compute the value of the const. This will require some break change. There are different alternatives here:
  • Never promote anything that might fail -- this breaks some real code (no idea how much, it's only 2 crates in crater), but leads to a rather clean situation.
  • Only promote things that fail if they are in parts of the CFG that will definitely be evaluated -- that will however be rather surprising behavior, so maybe we want to do this only for old editions. In particular, a proper post-dominance analysis might be too expensive, so we might just check if the entire CFG is linear, or we only promote on the "linear head" of the CFG; in either case, adding a conditional somewhere in the code will stop promotion of things further down that code, which is rather odd.

[Aaron1011]

Never promote anything that might fail -- this breaks some real code (no idea how much, it's only 2 crates in crater), but leads to a rather clean situation.

Can that code be made to compile with inline const blocks?

[RalfJung]

@Aaron1011 yes it can, but only once inline const blocks can use generics of the surrounding context.

[RalfJung]

I think this is probably the best option:

Live with the fact that promoteds in const/static initializers can fail even if they are not required for said initializer. This means no breaking change here, but it will require care in MIR optimizations, MIR printing, maybe more.

#85112 ensures that at least a normal build handles this correctly. @oli-obk any idea how to check other MIR consumers such as MIR printing for this?

[oli-obk]

MIR printing should just print the path to unevaluated constants and not eval them at all. The only other thing would be optimizations, but these aren't run for constants' bodies

[RalfJung]

MIR printing should just print the path to unevaluated constants and not eval them at all.

As in, it already does that, or it should be changed to do that?

[oli-obk]

I believe it does that. At least I specifically remember seeing paths being printed for things that could have been evaluated.