4 ms·

> To avoid having long compilations without feedback, the compiler will always emit a message after your compile-time code has been running for a while, and rep

> To avoid having long compilations without feedback, the compiler will always emit a message after your compile-time code has been running for a while, and repeat that message after a period that doubles each time. Is this "period" measured in statements or computer time? > By default, the compiler will also emit a deny-by-default lint (const_eval_long_running) after a large number of steps to catch infinite loops, but you can allow(const_eval_long_running) to permit especially long const evaluation. 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)? If rustc "catches" infinite loops by default, how is backwards compatibility preserved with respect to `const` functions? If I split one statement into two in `const fn`, do I break BC?

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 ago
    Rustc 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.
connicpu 3y ago
It's backwards compatible because the old behavior was to simply make long evaluations an error every time. The new system gives you the option to allow a long evaluation if you opt in
- SkiFire13 3y ago
  I think OP is looking at backward compatibility with respect to libraries. For example today I make a library that does a lot of computations in `const` functions and it works with rust 1.72.0; tomorrow I slightly change function by splitting a statement into two, and now suddently the evaluation becomes too long and my dependents don't compile anymore. Though to be honest this problem existed even before rust 1.72.0 and likely can't be solved while preventing infinite computations.
  - Hirrolot 3y ago
    Exactly. The point is that most Rust libraries use semantic versioning, which actually forces you to determine if the change you've made to your library is backwards-compatible or not. I think it's a good practice but it's unclear to me how it should be applied to `const` functions.
  - mirashii 3y ago
    > it works with rust 1.72.0; tomorrow I slightly change function by splitting a statement into two, and now suddently the evaluation becomes too long and my dependents don't compile anymore. Just to be clear, this was the case before the new changes in 1.72. They already had that limit, and code could break in exactly that way. There were two problems with that beyond the simple backwards compatibility break. One is that there was no opt out, so if you broke you were kinda hosed at the library level. The second is that the limit was relatively low and so it was very possible to hit it. Now if you end up running too long and the compiler fails, you’ve at least got an opt out, and the limit before failure is much higher.
derefr 3y ago
> Why not make the default behaviour to just notify a user by emitting a message after some time (as described)? Presumably for the sake of people who blindly upgrade an automated Rust build toolchain and wouldn't be aware that this would be signing them up for potentially-unbounded build times (and therefore potentially-unbounded CI/CD service fees.)

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 ago
  Rustc 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.

connicpu 3y ago

It's backwards compatible because the old behavior was to simply make long evaluations an error every time. The new system gives you the option to allow a long evaluation if you opt in

SkiFire13 3y ago
I think OP is looking at backward compatibility with respect to libraries. For example today I make a library that does a lot of computations in `const` functions and it works with rust 1.72.0; tomorrow I slightly change function by splitting a statement into two, and now suddently the evaluation becomes too long and my dependents don't compile anymore. Though to be honest this problem existed even before rust 1.72.0 and likely can't be solved while preventing infinite computations.
- Hirrolot 3y ago
  Exactly. The point is that most Rust libraries use semantic versioning, which actually forces you to determine if the change you've made to your library is backwards-compatible or not. I think it's a good practice but it's unclear to me how it should be applied to `const` functions.
- mirashii 3y ago
  > it works with rust 1.72.0; tomorrow I slightly change function by splitting a statement into two, and now suddently the evaluation becomes too long and my dependents don't compile anymore. Just to be clear, this was the case before the new changes in 1.72. They already had that limit, and code could break in exactly that way. There were two problems with that beyond the simple backwards compatibility break. One is that there was no opt out, so if you broke you were kinda hosed at the library level. The second is that the limit was relatively low and so it was very possible to hit it. Now if you end up running too long and the compiler fails, you’ve at least got an opt out, and the limit before failure is much higher.

derefr 3y ago

> Why not make the default behaviour to just notify a user by emitting a message after some time (as described)? Presumably for the sake of people who blindly upgrade an automated Rust build toolchain and wouldn't be aware that this would be signing them up for potentially-unbounded build times (and therefore potentially-unbounded CI/CD service fees.)