Hacker News Reader

Comment by Hirrolot | Hacker News Reader

> 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?

View on HN

> 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

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

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.

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

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.

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.

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

> 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.)

Reply on news.ycombinator.com