loop_match: suggest extracting to a const item

[folkertdev]

tracking issue: #132306
fixes #143310

[RalfJung]

Sorry, I won't be able to review this.
r? @oli-obk

[folkertdev]

As additional context, #143310 shows that this suggestion doesn't work (but it should). We get

https://godbolt.org/z/zvs9ePzdj

error[E0391]: cycle detected when building MIR for `break_on_constant_evalution`
  --> <source>:20:32
   |
20 |                     break 'blk const{ const_fn() };
   |                                ^^^^^^^^^^^^^^^^^^^
   |
note: ...which requires evaluating type-level constant...
  --> <source>:20:37
   |
20 |                     break 'blk const{ const_fn() };
   |                                     ^^^^^^^^^^^^^^
note: ...which requires const-evaluating + checking `break_on_constant_evalution::{constant#0}`...
  --> <source>:20:37
   |
20 |                     break 'blk const{ const_fn() };
   |                                     ^^^^^^^^^^^^^^
note: ...which requires caching mir of `break_on_constant_evalution::{constant#0}` for CTFE...
  --> <source>:20:37
   |
20 |                     break 'blk const{ const_fn() };
   |                                     ^^^^^^^^^^^^^^
note: ...which requires elaborating drops for `break_on_constant_evalution::{constant#0}`...

And I'm not sure why. We must be evaluating the constant in some sort of unexpected way, but I really don't know enough about const eval to troubleshoot it.

[oli-obk]

const blocks are nested within their parent and borrowchecked together with them, so in order to drop elaborate the constant we need to borrowck the parent, and that depends on MIR building of the parent again (which is when you're evaluating the const). To avoid this you need to put the const into a separate item, not a const block. This means you lose access to generic params, but that's probably a good thing similar to how const blocks in patterns being affected by generic params is fishy

[folkertdev]

Right, but what confuses me is why the example does work when I comment out the loop-match attributes, like here https://godbolt.org/z/66q98PeW9.

[RalfJung]

Why is that surprising? If you don't use the attributes, then your code doesn't run, so it can't ICE.

It is fundamentally not possible to evaluate constants during MIR building. The constant could be generic, and MIR building happens pre-monomorphization, so the value of generics is not known yet. For the same reason, you cannot use constants that use generic in patterns.

[RalfJung]

So this has to enforce the same restrictions as patterns: only named constants without any generics in their path. It shouldn't ICE, of course. But unfortunately const blocks do not work.

After all, the entire point if this construct is to hard-code where this jumps to; if that could depend on generics, then it couldn't be hard-coded into the MIR.

[folkertdev]

Hmm, you mean that loop-match evaluates the const { ... } too early? It must evaluate it at compile-time at some point right, so whether the code runs doesn't seem relevant. Also this const { ... } block doesn´t use generics in practice so I think that added to my confusion (but it's probably hard to figure that out at that point).

Anyway, that means we should suggest using a const item, not a const expression.

[RalfJung]

Hmm, you mean that loop-match evaluates the const { ... } too early?

Yes. In general, it can only be evaluated during monomorphization.

It must evaluate it at compile-time at some point right,

Sure, but there's many different stages of compile-time and it makes a big difference when (i.e., in which stage) code runs. In particular, there's the key distinction of "are generics still present or have they been monomorphized away already".

So, this is very relevant. It seems you are fundamentally confused about how generic functions work in rustc; please let's take any further questions you may have here to Zulip.

this const { ... } block doesn´t use generics

Yeah, for this const block the ICE comes from the borrow checker as Oli explained.
But we also don't actually detect whether a const block needs some generic or not, we just give all the surrounding generics to const blocks. Surely it would be very confusing if const { ... } worked in loop_match but only in non-generic functions.

I missed this problem with generics when I wrote my comment in #143310, sorry for that.

[folkertdev]

I just hadn't considered generics given that the concrete example didn't have them. But it makes sense that they must be taken into account now. Thanks for the background!

[folkertdev]

Allright, the error now suggests to extract to a const item, and gives some specific extra information when using const parameters or const blocks, because it seems like those should work, but for good technical reasons they cannot.