Allow `loop` in constant evaluation #2344

oli-obk · 2018-02-22T13:45:25Z

Centril

All for this change 👍
I have some mostly minor, hopefully helpful, thoughts =)

Centril · 2018-02-22T14:24:27Z

text/0000-const-looping.md

+
+Allow the use of `loop`, `while` and `while let` during constant evaluation.
+`for` loops are technically allowed, too, but can't be used in practice because
+each iteration calls `iterator.next()`, which is not a `const fn` and thus can't


Linking #2237 which (or a modified version of which) will fix that and let you use iter.next() in const fn.

Centril · 2018-02-22T14:25:20Z

text/0000-const-looping.md

+# Motivation
+[motivation]: #motivation
+
+Any iteration is expressible as a recursion. Since we already allow recursion


Small possible improvement: s/a recursion/with recursion.

Centril · 2018-02-22T14:26:15Z

text/0000-const-looping.md

+
+Any iteration is expressible as a recursion. Since we already allow recursion
+via const fn and termination of said recursion via `if` or `match`, all code
+enabled by const recursion is already legal now. Writing loops with recursion is


Does this hold given recursion depth limits?

yea, if the loop takes too many iterations you'll hit the limit, but that's not much of an issue imo, since you can always work around that with unrolling or similar tricks.

Ah, thanks for explaining =)

Still... might it be good to allow users to raise the limit from the default so that it is not so fixed and so that you can fix cases wherein you know that termination is guaranteed but rustc complains nonetheless?

Centril · 2018-02-22T14:32:49Z

text/0000-const-looping.md

+via const fn and termination of said recursion via `if` or `match`, all code
+enabled by const recursion is already legal now. Writing loops with recursion is
+very tedious and can quickly become unreadable, while regular loops are much
+more natural in Rust.


This feels like a somewhat bold assertion that seems to suggest that functional languages are less readable, while I'd argue that the opposite is the case, recursion is often more readable than loops - and iteration combinators using map, filter, fold even more so (tho combinators have nothing to do with recursion).

I agree that regular loops are more used in Rust, but I believe this has more to do with the lack of guaranteed TCO (Tail Call Optimization, https://en.wikipedia.org/wiki/Tail_call, https://stackoverflow.com/questions/310974/what-is-tail-call-optimization) which RFC #1888 attempts to address.

I don't think any of these assertions are necessary to motivate loops in const fn - feature parity alone and the feeling that the language is uniform when you switch from fn -> const fn should be enough.

Centril · 2018-02-22T14:35:35Z

text/0000-const-looping.md

+[guide-level-explanation]: #guide-level-explanation
+
+If you previously had to write functional code inside constants, you can now
+change it to imperative code. For example if you wrote a fibonacci like


Who doesn't love a fibonacci example =P This section feels very nicely written!
Stylistically I'ld do: s/like/like: (and before the other sections as well..)

Centril · 2018-02-22T14:36:33Z

text/0000-const-looping.md

+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+A loop in MIR is a cyclic graph of BasicBlocks. Evaluating such a loop is no


s/BasicBlocks/BasicBlocks

Centril · 2018-02-22T14:38:23Z

text/0000-const-looping.md

+different from evaluating a linear sequence of BasicBlocks, except that
+termination is not guaranteed. To ensure that the compiler never hangs
+indefinitely, we count the number of terminators processed and once we reach a
+fixed limit, we report an error mentioning that we aborted constant evaluation,


Perhaps a word about if and how you can control that fixed limit? (I assume the #[recursion_limit = "<limit>"] attribute?)

there's no such attribute

Not this? https://github.com/rust-lang/rust/blob/master/src/librustc/middle/recursion_limit.rs
rust-lang/rust#28000

That's a different recursion. Recursing in const eval does not actually cause recursion in the compiler, just more elements in the virtual stack Vec.

Centril · 2018-02-22T14:40:25Z

text/0000-const-looping.md

+# Drawbacks
+[drawbacks]: #drawbacks
+
+* Loops are not guaranteed to terminate


Nicely written.

In the far future it might be interesting to have a total effect in the language with a totality checker that guarantees termination.

Do we have a mechanism to adjust the amount of compile-time evaluation allowed, similar to the macro limits?

Nope, but it's trivial to add (a single line next to the recursion limit attr code)

scottmcm · 2018-02-24T09:46:46Z

Just counting all terminators worries me slightly that a tweak to MIR optimizations or HIR->MIR lowering will result in code that happened to be right on the edge breaking in an update.

Is there some tweak to the rule that's more resilient to otherwise-invisible changes, and where it's easier to understand by looking at your code how many of whatever it's counting you're taking? Like maybe only counting backedges taken. (Though even that changes for loop unrolling, I guess.)

Come to think of it, I wonder if the recursion limit means that the MIR inliner should add a new marker statement to the MIR so that heuristic changes don't change how many times a function recurses...

oli-obk · 2018-02-24T13:09:04Z

Well.... the current limit is riddiculously high. 1 million terminators take a while to evaluate.

We could also hash the entire state at every terminator and detect true loops this way. We could even only do that once we reach the limit so we don't slow down the regular evaluations.

oli-obk · 2018-02-24T13:11:39Z

We could emit a warning for long evaluations so ppl know rustc isn't hanging, just busy

burdges · 2018-02-24T13:24:18Z

Also test builds could report how much time was spent in rustc itself vs const evaluation, so slow crates get blamed quickly.

Centril · 2018-02-24T13:42:53Z

Well.... the current limit is riddiculously high. 1 million terminators take a while to evaluate.

Do you have some guess as to how much a while might be? Just so we're on the same page =)

oli-obk · 2018-02-24T16:16:21Z

While that depends on the code you're executing, experience with when the limit was on statements was several minutes

Edit: with the hash checker we could set it to seconds so ppl get feedback fast

nagisa · 2018-02-24T17:57:17Z

We should not have any error on constant evaluation by default. Not time and not terminator count based. Instead, there should exist a lint of-sorts that would warn every so often that such-and-such constant item is still being evaluated, and that’s it. People who want to make sure stuff doesn’t get out of hand can then #[deny] it and people who know they gonna do heavy compile-time computations can #[allow] it so the compiler doesn’t nag at them too much.

So basically what this says.

joshtriplett · 2018-02-24T20:38:03Z

@nagisa I'd be concerned about people running automated builds and finding that they take forever, in that case. CI, for instance. Having an overridable stall detector on by default seems like a feature.

nagisa · 2018-02-24T22:49:23Z

@joshtriplett Sure, hence #[deny]. Of course we still would need to provide a way to configure actual limit. Most importantly, with this approach breaking code which uses #[deny(long_const_eval)] would be about as breaking as breaking code which specifies #[deny(warnings)] (we do not consider it to be a breaking change).

clarfonthey · 2018-02-28T20:41:09Z

Considering how Rust's type system is turing complete, infinite compile loops are already possible. This just makes them a bit easier.

oli-obk · 2018-02-28T21:13:28Z

To the best of my knowledge you can't do infinite loops in the type system without hitting the recursion limit. True recursions would trigger an error of the form "needed X to compute X"

clarfonthey · 2018-03-01T05:21:01Z

That makes sense. Perhaps the an iteration limit could be equivalent to the recursion limit?

oli-obk · 2018-03-01T07:21:53Z

They are different, because now there can be repetitive recursions. I think going with the warning and no limit is the way to go. I'll change the RFC accordingly

@nagisa

Don't abort const eval due to long running evals, just warn one check-box of #49930 r? @nagisa (rust-lang/rfcs#2344 (comment))

oli-obk · 2018-04-24T16:03:39Z

Long running const eval doesn't cause errors anymore: rust-lang/rust#49980

pnkfelix · 2018-05-14T14:02:49Z

text/0000-const-looping.md

+# Drawbacks
+[drawbacks]: #drawbacks
+
+* Infinite loops will hang the compiler if the lint is not denied


Nit: Even just a #[warn] on the lint will cause warning output to occur (and repeat ad nauseaum) in response to an infinite loop, right? Usually when I hear "hang" I think of "no output visible"... so I would personally have written "if the lint is #[allow]'ed" here. But that might just be my own personal interpretation.

pnkfelix · 2018-05-14T14:06:13Z

text/0000-const-looping.md

+indefinitely, we count the number of terminators processed and whenever we reach
+a fixed limit, we report a lint mentioning that we cannot guarantee that the
+evaluation will terminate and reset the counter to zero. This lint should recur
+in a non-annoying amount of time (e.g. at least 30 seconds between occurrences).


So just to be clear: the const-eval state will include both a terminator-counter and a timestamp; When the terminator-counter both 1. exceeds the (here unspecified) fixed limit, and 2. the current time delta from the timestamp is non-annoying, then we report the lint, reset the terminator-counter and timestamp, and finally resume const-eval execution?

(I'm just checking that there's not a typo here and that we are planning on using both pieces of state for the filter here, something of which I am in favor.)

The current implementation just has a MIR terminator counter for the warning. There's no host time check. Shouldn't be too hard to add.

I just want to clarify the end-intent. The current implementation isn't really something that concerns me all that much. :)

pnkfelix · 2018-05-14T14:09:38Z

@rfcbot fcp merge

(I usually construct a comment thread summary before issuing the rfcbot command, but in this case I think all of the relevant comments were addressed, usually via incorporation into the RFC text, so I'm able to just recommend that people read the RFC.)

rfcbot · 2018-05-14T14:09:38Z

Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rfcbot · 2018-06-22T17:50:01Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2018-07-02T17:50:38Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

Centril · 2018-07-02T18:33:20Z

Huzzah! This RFC is now merged!

Tracking issue: rust-lang/rust#52000

Allow loop in constant evaluation

bcffd35

Centril added the T-lang Relevant to the language team, which will review and decide on the RFC. label Feb 22, 2018

Centril reviewed Feb 22, 2018

View reviewed changes

Address comments

5d3d23d

Don't error on long const evals

4c884b4

This was referenced Apr 13, 2018

Constant evaluation regression in beta 1.26 rust-lang/rust#49930

Closed

Don't abort const eval due to long running evals, just warn rust-lang/rust#49947

Merged

bors added a commit to rust-lang/rust that referenced this pull request Apr 15, 2018

Auto merge of #49947 - oli-obk:turing_complete_const_eval, r=nagisa

8de5353

Don't abort const eval due to long running evals, just warn one check-box of #49930 r? @nagisa (rust-lang/rfcs#2344 (comment))

oli-obk mentioned this pull request May 9, 2018

Tracking issue for const_size_of_val and const_align_of_val rust-lang/rust#46571

Closed

scottmcm mentioned this pull request May 11, 2018

rustc infinite loop: warning: Constant evaluating a complex constant, this might take some time rust-lang/rust#50637

Closed

pnkfelix reviewed May 14, 2018

View reviewed changes

rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. labels May 14, 2018

Address nits

ee780e9

rfcbot added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels Jun 22, 2018

rfcbot added finished-final-comment-period The final comment period is finished for this RFC. and removed final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels Jul 2, 2018

Centril mentioned this pull request Jul 2, 2018

Tracking issue for RFC 2344, "Allow loop in constant evaluation" rust-lang/rust#52000

Closed

3 tasks

RFC 2344

e4ac9b0

Centril merged commit c794c75 into rust-lang:master Jul 2, 2018

Centril added A-typesystem Type system related proposals & ideas A-machine Proposals relating to Rust's abstract machine. A-control-flow Proposals relating to control flow. A-const-eval Proposals relating to compile time evaluation (CTFE). labels Nov 23, 2018

oli-obk deleted the const_looping branch May 31, 2020 13:14

Allow loop in constant evaluation #2344

Allow loop in constant evaluation #2344

Conversation

oli-obk commented Feb 22, 2018 • edited by Centril Loading

Centril left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Centril Feb 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

scottmcm commented Feb 24, 2018

oli-obk commented Feb 24, 2018

oli-obk commented Feb 24, 2018

burdges commented Feb 24, 2018

Centril commented Feb 24, 2018

oli-obk commented Feb 24, 2018 • edited Loading

nagisa commented Feb 24, 2018

joshtriplett commented Feb 24, 2018 • edited Loading

nagisa commented Feb 24, 2018

clarfonthey commented Feb 28, 2018

oli-obk commented Feb 28, 2018

clarfonthey commented Mar 1, 2018

oli-obk commented Mar 1, 2018

oli-obk commented Apr 24, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pnkfelix commented May 14, 2018

rfcbot commented May 14, 2018 • edited by aturon Loading

rfcbot commented Jun 22, 2018

rfcbot commented Jul 2, 2018

Centril commented Jul 2, 2018

Allow `loop` in constant evaluation #2344

Allow `loop` in constant evaluation #2344

oli-obk commented Feb 22, 2018 •

edited by Centril

Loading

Centril Feb 22, 2018 •

edited

Loading

oli-obk commented Feb 24, 2018 •

edited

Loading

joshtriplett commented Feb 24, 2018 •

edited

Loading

rfcbot commented May 14, 2018 •

edited by aturon

Loading