Infinite loops crash the compiler

[asterite]

Aim

This code:

fn main() {
    /// Safety:
    unsafe {
        some_loop();
    }
}

unconstrained fn some_loop() {
    let mut i = 0;
    loop {
        println(i);
        i += 1;
    }
}

Expected Behavior

Expected the code to compile and execute well.

Bug

It leads to a crash:

The application panicked (crashed).
Message:  Expected a return instruction, as function construction is finished
Location: compiler/noirc_evaluator/src/ssa/ir/function.rs:180

If we change the failing function to handle empty return values, then we must do more things:

• The SSA inliner code will crash now in a place it expects at least one return. This can be changed to return Vec::new() in that case.
• There's an SSA optimization that tries to evaluate brillig calls with all constants. It must be changed so that if that function has no returns, don't try to evaluate it (it hangs the compiler)
• There's a similar optimization when generating brillig from SSA when we attempt to evaluate brillig, so a similar change must be done there

But even then the compiler crashes with this:

The application panicked (crashed).
Message:  ICE: Value not found in cache v13
Location: compiler/noirc_evaluator/src/brillig/brillig_gen/brillig_block_variables.rs:46

To Reproduce

Workaround

None

Workaround Description

No response

Additional Context

No response

Project Impact

None

Blocker Context

No response

Nargo Version

No response

NoirJS Version

No response

Proving Backend Tooling & Version

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

[aakoshh]

Perhaps it could also be handled similarly to #6292

[jfecher]

SSA in general isn't really equipped to deal with alternate looping constructs. Not only do we assume every function has exactly one return, there are also assumptions on a loop's block structure in the loop unrolling pass (pre-header, header, body blocks). This block structure has been relaxed over time to return optionals but I wouldn't be surprised if that pass finds a block before the infinite loop which happens to start with a < instruction and identifies it as the header of the loop.

This is fixable though. I'd definitely be fine with erroring if the loop doesn't contain at least 1 break as well. Identifying whether the break is reachable or not correctly in all cases is impossible so we don't need to try especially for a first pass at this. We could add a warning/error later if the break is known unreachable though. We'll probably know this somewhere in SSA.