3 ms·
> Is this "period" measured in statements or computer time? It sounds like computer time is used now. > So the default behaviour now is to nonetheless "catch"
by Guvante 3y ago
> Is this "period" measured in statements or computer time?
It sounds like computer time is used now.
> So the default behaviour now is to nonetheless "catch" infinite loops by default? Why not make the default behaviour to just notify a user by emitting a message after some time (as described)?
Because lots of builds don't have a user. Having the user have to time out rustc because of this would be frustrating.
> If rustc "catches" infinite loops by default, how is backwards compatibility preserved with respect to `const` functions?
As long as the time is much larger than it takes to handle the old statement limit it is preserved.
> If I split one statement into two in `const fn`, do I break BC?
The old version might have prevented your code from compiling as mentioned in the notes.
The new version should in theory allow it if the unsplit version worked since it is based off compilation time.
Also there is an opt flag where it will go infinite
- Hirrolot 3y ago> As long as the time is much larger than it takes to handle the old statement limit it is preserved. As a library developer, how can I know that? > The old version might have prevented your code from compiling as mentioned in the notes. Does it mean that rustc tracks function BC? I think I've misunderstood you.
- Guvante 3y agoRustc guarantees code that compile before continues to compile. In this case they modified the old hard error that you could opt out of into a deny by default lint. Additionally if you opt out of the lint you get progress notifications of how much work has been done. Looks like the whole thing is still statement based to avoid slow machines breaking on a timer.