Infinite loop detection for const evaluation
Resolves#50637.
An `EvalContext` stores the transient state (stack, heap, etc.) of the MIRI virtual machine while it executing code. As long as MIRI only executes pure functions, we can detect if a program is in a state where it will never terminate by periodically taking a "snapshot" of this transient state and comparing it to previous ones. If any two states are exactly equal, the machine must be in an infinite loop.
Instead of fully cloning a snapshot every time the detector is run, we store a snapshot's hash. Only when a hash collision occurs do we fully clone the interpreter state. Future snapshots which cause a collision will be compared against this clone, causing the interpreter to abort if they are equal.
At the moment, snapshots are not taken until MIRI has progressed a certain amount. After this threshold, snapshots are taken every `DETECTOR_SNAPSHOT_PERIOD` steps. This means that an infinite loop with period `P` will be detected after a maximum of `2 * P * DETECTOR_SNAPSHOT_PERIOD` interpreter steps. The factor of 2 arises because we only clone a snapshot after it causes a hash collision.
This test relies on the fact that restrictions on expressions in `const
fn` do not apply when computing array lengths. It is more difficult to
statically analyze than the simple `loop{}` mentioned in #50637.
This test should be updated to ignore the warning after #49980 is resolved.
Make the `const_err` lint `deny`-by-default
At best these things are runtime panics (debug mode) or overflows (release mode). More likely they are public constants that are unused in the crate declaring them.
This is not a breaking change, as dependencies won't break and root crates can `#![warn(const_err)]`, though I don't know why anyone would do that.
Allow variant discriminant initializers to refer to other initializer…
…s of the same enum
r? @eddyb
fixes the 2.4 failure of https://github.com/rust-lang/rust/issues/49765
cc @durka @retep998
