Repository navigation
Tracking issue for RFC 2344, "Allow loop in constant evaluation" #52000
Description
This is a tracking issue for the RFC "Allow loop in constant evaluation" (rust-lang/rfcs#2344).
Steps:
- Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
- Adjust documentation (see instructions on forge)
- Stabilization PR (see instructions on forge)
Unresolved questions:
- Should we add a true recursion check that hashes the interpreter state and detects if it has reached the same state again?
- This will slow down const evaluation enormously and for complex iterations is essentially useless because it'll take forever (e.g. counting from 0 to
u64::max_value())
- This will slow down const evaluation enormously and for complex iterations is essentially useless because it'll take forever (e.g. counting from 0 to
Reacted by Stepan Koltsov, hugecheese, Robin Freyler, Smitty, Jonathan, Simon, Jacob Pratt, Stanislav Tkach, Eyal Kalderon, Igor Aleksanov and 11 more
Reacted by Bruno Dutra, Kyle J Strand, Jeff VanDyke, Kenta Moriuchi, Alex Gaynor, Gurwinder Singh, hugecheese, Clément Renault, jerryc05, Marius Cobzarenco and 4 more
Reacted by Ricardo Fernández Serrata
Activity
brunocodutra commentedon Jul 21, 2018
This feature seems simple enough for me to tackle as my first attempt to contribute to rust, at least getting it to work appears to be as simple as removing the check against loops in constant functions.
I believe the real work actually goes into implementing the lint for potential infinite loops. I'm going to tackle this next and I'd really appreciate some mentorship along the way.
oli-obk commentedon Jul 21, 2018
Implementing this feature is blocked on a bunch of definitely not beginner level things. But there's ongoing preliminary work happening, so this isn't standing still even if nothing happens on the issue.
If we'd just remove the check against loops, we'd end up with amusingly broken code, because most of the const checking code only knows it needs to prevent writing multiple times to a variable... which loops can do without naming the variable twice.
Anyway, guarding against infinite loops has been partially implemented, and if you're interested in doing some work there, we're tracking one of the issues in #52475
brunocodutra commentedon Jul 21, 2018
Thanks for pointing me to the right direction, I'll definitely have a look for something I can help with.
jkarns275 commentedon Aug 23, 2018
Would an iteration limit be an acceptable solution to the the infinite loop problem? If the iteration limit is actually reached the code can just be compiled instead!
Though this may be deceptive since the const fns wouldn't really be const if the limit is reached.
estebank commentedon Aug 23, 2018
It could be a compilation error, which would let the
const fncontinue to beconst(code that fails to compile has no bearing in execution time ^_^).jkarns275 commentedon Aug 23, 2018
True! Perhaps it would be worth adding a compilation option of some sort that would make it just a warning for edge cases.
Edit: reading this half a year later and i have no idea what i meant
BatmanAoD commentedon Jan 24, 2019
@oli-obk
....sorry, I thought that compile-time evaluated code is run by MIRI; why would it matter whether a variable is written to multiple times?
Of course, any (useful) compile-time evaluation is ultimately going to result in
staticdata in the resulting executable, so it makes sense forconstvalues not to be written to multiple times. But shouldn't that already be guaranteed by mutability rules?BatmanAoD commentedon Jan 24, 2019
Additionally, if the
Itertrait were to be stabilized for use inconst fncontexts, I think an entirely reasonable resolution to this issue would be to enable only loops that rely onIter. This would permit many simple obviously-terminating loops (the most obvious example being those iterating over range-literals), while limiting the potential for unbounded compiler execution to problems in the implementation of the iterator used.An even simpler and forward-compatible solution would be to only permit iteration over range-literals for now.
44 remaining items
rfcbot commentedon Jun 15, 2020
🔔 This is now entering its final comment period, as per the review above. 🔔
rfcbot commentedon Jun 25, 2020
The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
The RFC will be merged soon.
Rollup merge of rust-lang#72437 - ecstatic-morse:stabilize-const-if-m…
Rollup merge of rust-lang#72437 - ecstatic-morse:stabilize-const-if-m…
jonas-schievink commentedon Jun 29, 2020
Stabilized in #72437 🎉
Do not ignore the lockfile during a CI run
Do not ignore the lockfile during a CI run