Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix eval_global_as_array_length to support non-array-length types #6238

Closed
2 tasks
michaeljklein opened this issue Oct 8, 2024 · 1 comment · Fixed by #6469
Closed
2 tasks

Fix eval_global_as_array_length to support non-array-length types #6238

michaeljklein opened this issue Oct 8, 2024 · 1 comment · Fixed by #6469
Assignees
@michaeljklein
Labels
bug Something isn't working

Comments

@michaeljklein
Copy link
Contributor

michaeljklein commented Oct 8, 2024 •
edited
Loading

Aim

#6137 adds the warning EvaluatedGlobalIsntU32 when eval_global_as_array_length is used on non-u32 types.

This is connected to the following (test: issue) pairs:

Expected Behavior

eval_global_as_array_length to either handle larger types, e.g. Field properly, or to only be used when the globals are within the expected range

TODO:

  • See how much overlap there between the evaluate global as array length function and the comptime interpreter code: (some of) the comptime interpreter method(s) may be usable here
  • Test that we error for overflowing in intermediate u32 kind computations, e.g. the equivalent of U32_MAX + 1 - X where X > 0

Bug

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
@michaeljklein michaeljklein added the bug Something isn't working label Oct 8, 2024
@michaeljklein michaeljklein self-assigned this Oct 8, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Oct 8, 2024
@michaeljklein michaeljklein mentioned this issue Oct 9, 2024
Merged
6 tasks
michaeljklein added a commit that referenced this issue Oct 9, 2024
@michaeljklein
disable warning check in compile_success_empty for brillig_cast and m…
0ff3731 
…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
@michaeljklein @TomAFrench
@vezenovm @jfecher
feat!: kind size checks (#6137)
6e40f62 
# 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 <15848336+TomAFrench@users.noreply.github.com>
Co-authored-by: Maxim Vezenov <mvezenov@gmail.com>
Co-authored-by: jfecher <jake@aztecprotocol.com>
@michaeljklein
Copy link
Contributor Author

Current plan:

  • Resolve globals to:
    1. Type::InfixExpr / Type::Constant if possible
    • Where nested globals can be appx. Type::Global(GlobalId)
    1. comptime globals otherwise (to allow using the existing interpreter)
    • Require such globals to be explicitly comptime
  • Use existing type-checking and interpreting code paths instead of eval_global_as_array_length

@michaeljklein michaeljklein mentioned this issue Nov 7, 2024
Merged
5 tasks
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@michaeljklein michaeljklein

Labels
bug Something isn't working
Projects
Noir
Status: ✅ Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: replace eval_global_as_array_length with type/interpreter evaluation noir-lang/noir
1 participant
@michaeljklein