Closed
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
Metadata
Metadata
Assignees
Labels
Area: Constant evaluation, covers all const contexts (static, const fn, ...)Blocker: Approved by a merged RFC but not yet implemented.Category: An issue tracking the progress of sth. like the implementation of an RFCRelevant to the language teamThis issue / PR is in PFCP or FCP with a disposition to merge it.The final comment period is finished for this PR / Issue.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
loop
in constant evaluation rust-lang/rfcs#2344brunocodutra 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 fn
continue 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
83 remaining items