Fix eval_global_as_array_length to support non-array-length types
#6238
Assignees
Labels
bug
Something isn't working
Comments
michaeljklein
added a commit
that referenced
this issue
Oct 9, 2024
…acros_in_comptime (which currently emit a warning as per #6238)
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 9, 2024
# Description ## Problem\* * Need to check that type constants fit into their `Kind`'s * The sizes of results from `op.function` and `evaluate_to_u32` are unchecked ## Summary\* Split out from #6094 - Some parts only work with its additional kind information - Several follow up issues, including: * #6247 * #6245 * #6238 ## Additional Context TODO: - [x] Add this test and/or similar execution tests unless we already have a similar one (sanity-check that global `Field` arithmetic works past `u32::MAX`) ```noir // 2^32 + 1 global A: Field = 4294967297; global B: Field = 4294967297; global C: Field = A + B; fn main() { // 2 * (2^32 + 1) assert(C == 8589934594); let mut leading_zeroes = 0; let mut stop = false; let bits: [u1; 64] = C.to_be_bits(); for i in 0..64 { if (bits[i] == 0) & !stop { leading_zeroes += 1; } else { stop = true; } } let size = 64 - leading_zeroes; // 8589934594 has 34 bits assert(size == 34); } ``` ## Documentation\* Check one: - [x] No documentation needed. - [ ] Documentation included in this PR. - [ ] **[For Experimental Features]** Documentation to be submitted in a separate PR. # PR Checklist\* - [x] I have tested the changes locally. - [x] I have formatted the changes with [Prettier](https://prettier.io/) and/or `cargo fmt` on default settings. --------- Co-authored-by: Tom French <[email protected]> Co-authored-by: Maxim Vezenov <[email protected]> Co-authored-by: jfecher <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Aim
#6137 adds the warning
EvaluatedGlobalIsntU32wheneval_global_as_array_lengthis used on non-u32types.This is connected to the following (
test: issue) pairs:numeric_generic_field_larger_than_u32: Using largeField's in numeric generics fails with "array length too large" #6125numeric_generic_field_arithmetic_larger_than_u32:Fieldcomputed to be larger thanu32::MAXwith arithmetic generics panics #6126Expected Behavior
eval_global_as_array_lengthto either handle larger types, e.g.Fieldproperly, or to only be used when the globals are within the expected rangeTODO:
u32kind computations, e.g. the equivalent ofU32_MAX + 1 - XwhereX > 0Bug
numeric_generic_field_larger_than_u32: Using largeField's in numeric generics fails with "array length too large" #6125numeric_generic_field_arithmetic_larger_than_u32:Fieldcomputed to be larger thanu32::MAXwith arithmetic generics panics #6126To 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
The text was updated successfully, but these errors were encountered: