feat: replace eval_global_as_array_length with type/interpreter evaluation

[michaeljklein]

Description

Problem*

• Resolves Using large Field's in numeric generics fails with "array length too large" #6125
• Resolves Field computed to be larger than u32::MAX with arithmetic generics panics #6126
• Resolves Fix eval_global_as_array_length to support non-array-length types #6238

Summary*

All globals are now comptime

Additional Context

Cyclic globals now stack overflow since that's the behavior of comptime cyclic globals before this PR (#6780)

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.

[TomAFrench]

Discussed in 1:1 that we're going to require globals to have their type declared explicitly which also fixes the issues in this PR.

[github-actions]

Peak Memory Sample

Program	Peak Memory	%
keccak256	78.15M	1%
workspace	122.79M	0%
regression_4709	423.26M	54%
ram_blowup_regression	1.60G	0%
private-kernel-tail	206.67M	0%
private-kernel-reset	748.99M	0%
private-kernel-inner	312.95M	0%
parity-root	171.68M	1%

[github-actions]

Compilation Sample

Program	Compilation Time	%
sha256_regression	0m1.328s	-9%
regression_4709	0m0.805s	7%
ram_blowup_regression	0m14.654s	-6%
rollup-base-public	3m25.974s	-1%
rollup-base-private	3m3.970s	-1%
private-kernel-tail	0m1.565s	37%
private-kernel-reset	0m8.130s	0%
private-kernel-inner	0m2.522s	8%
parity-root	0m1.135s	29%
noir-contracts	2m38.634s	-5%

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: ef2e3ddf5cb0b2735716db04dc10b4d59112be03, compared to commit: 1b88adcb3c61cd832b6f45b46d5f99692599dbd0

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
poseidonsponge_x5_254	+3 ❌	+0.07%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
poseidonsponge_x5_254	4,254 (+3)	+0.07%

[jfecher]

👍

[asterite]

I think this broke Aztec-Packages contracts:

error: Comptime evaluation for builtin function 'as_field' is currently unimplemented
    ┌─ std/uint128.nr:143:17
    │
143 │         let f = crate::as_field(i);
    │                 ------------------
    │

error: Comptime evaluation for builtin function 'as_field' is currently unimplemented
    ┌─ std/uint128.nr:143:17
    │
143 │         let f = crate::as_field(i);
    │                 ------------------

I captured an issue for this, I'll try to fix it: #6828

[asterite]

That said, I don't know what are the valid types T for as_field and from_field... do you know?

[jfecher]

@asterite only the various integer types. It's an old builtin from before we had traits. We really should remove it and replace it with From<Field> and Into<Field>

[asterite]

There's one issue: it seems from_field will truncate the value to a Field, while I think From<Field> should panic if the Field value doesn't fit in the target type... right?

At first I did this:

impl From<Field> for u64 {
    fn from(value: Field) -> u64 {
        value.assert_max_bit_size::<64>();
        value as u64
    }
}

but I don't know if that would break things because the old code truncated.

Do you think we need a new private trait for this?

[jfecher]

I think panicking is fine but we should probably verify this. We should at least check the most common uses of this method.