if available on nightly, and
loop soon to follow, it's now feasible for users to write
const initializers that will run long enough to trigger the infinite loop detector. We should discuss if/how we want to limit the amount of time spent during const-eval by default. I described one possible configuration mechanism in #67217, along with the set of defaults I would like to see.
As I mention in the comments, I would like to have some way of disabling the infinite loop detector in the short-term, although I no longer think we need to block #67216 on it. It would be cool if we could decide on the interface for configuring time limits for const-eval relatively soon, and use that in the short-term to disable the loop detector, but it's not necessary.
An alternative to a configurable limit is to have a fixed limit that is controlled by a
long_running_const_eval lint. If you allow the lint, the infinite loop detector is disabled, and no limits are imposed on const-eval. If the lint is set to warn (the default), a warning will appear after that number of steps, and the infinite loop detector will start to trigger. If the lint is set to deny, reaching the fixed limit is a hard error.
TBH, I am not convinced the snapshot-based infinite loop detector is a good idea. IMO something simple like a basic-block-counter should be sufficient. But I won't block people if they want to go overboard with design here. ;)
However I'm afraid having both a fancy snapshot-based detector and a simple counter that interact in complex ways will be quite confusing.
yea, I just thought the snapshot loop detector was a great idea for UX, but it's so much stuff for little gain...
I'm fine with scrapping it
I'm gonna open a PR removing the loop detector after #67260 gets merged.
I think this is the right move, but I'm also feeling bad because you put so much work into it.