fix: detect cycles in globals

[asterite]

Description

Problem

Resolves #6780

Summary

This program:

comptime global A: u32 = B;
comptime global B: u32 = A;

fn main() { }

now gives these errors:

error: Variable not in scope
  ┌─ src/main.nr:2:26
  │
2 │ comptime global B: u32 = A;
  │                          - Could not find variable
  │

error: This global recursively depends on itself
  ┌─ src/main.nr:1:26
  │
1 │ comptime global A: u32 = B;
  │                          -
  │

error: Dependency cycle found
  ┌─ src/main.nr:1:17
  │
1 │ comptime global A: u32 = B;
  │                 - 'A' recursively depends on itself: A -> B -> A
  │

Aborting due to 3 previous errors

Additional Context

Documentation

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[github-actions]

Peak Memory Sample

Program	Peak Memory
keccak256	78.15M
workspace	122.62M
regression_4709	423.26M
ram_blowup_regression	1.58G
private-kernel-tail	206.71M
private-kernel-reset	720.29M
private-kernel-inner	291.91M
parity-root	171.71M

[github-actions]

Compilation Sample

Program	Compilation Time	%
sha256_regression	0m1.374s	-1%
regression_4709	0m0.838s	7%
ram_blowup_regression	0m14.549s	0%
rollup-base-public	3m33.736s	2%
rollup-base-private	3m3.473s	1%
private-kernel-tail	0m1.493s	26%
private-kernel-reset	0m7.754s	-4%
private-kernel-inner	0m2.326s	-1%
parity-root	0m0.886s	-9%
noir-contracts	2m57.923s	-5%

[vezenovm]

One thought, but LGTM

[jfecher]

LGTM. I don't see a way to avoid the double error, and double errors are already common when running comptime code. To avoid them we'd have to return something like Result<_, Option<Error>> which would get messy.

[asterite]

I was thinking of another way to do this, which is to do it similarly to FunctionBody:

pub enum FunctionBody {
    Unresolved(FunctionKind, BlockExpression, Span),
    Resolving,
    Resolved,
}

So a global's value would be a similar enum, and we wouldn't have to add a field to the interpreter. But I don't know which way is preferred...

[jfecher]

Either is fine, and either way you'd have to issue an extra error still

[asterite]

I just pushed a change for that. I think the code ends up a bit more clear, as it kind of forces us to handle the different states of a global's value.

[github-actions]

Execution Sample

Program	Execution Time	%
sha256_regression	0m0.601s	0%
regression_4709	0m0.394s	-9%
ram_blowup_regression	0m4.390s	-1%
rollup-base-public	0m28.294s	-1%
rollup-base-private	0m26.053s	-1%
private-kernel-tail	0m0.714s	-2%
private-kernel-reset	0m1.456s	-3%
private-kernel-inner	0m0.954s	-3%
parity-root	0m0.522s	-15%