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

global type is not inferred from usage when used in a type #6081

Closed
jfecher opened this issue Sep 18, 2024 · 0 comments · Fixed by #6083
Closed

global type is not inferred from usage when used in a type #6081

jfecher opened this issue Sep 18, 2024 · 0 comments · Fixed by #6083
Labels
bug Something isn't working

Comments

@jfecher
Copy link
Contributor

jfecher commented Sep 18, 2024

Aim

global FOO = 3;

fn main() {
    let x: [u32; FOO] = [1, 2, 3];
    println(x);
}

Expected Behavior

FOO should be inferred to be a u32 from being used in an array

Bug

error: Expected type [u32; 3], found type [Field; 3]
  ┌─ src/main.nr:4:25
  │
4 │     let x: [u32; FOO] = [1, 2, 3];
  │                         ---------
  │

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
@jfecher jfecher added the bug Something isn't working label Sep 18, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Sep 18, 2024
@jfecher jfecher mentioned this issue Sep 18, 2024
Merged
5 tasks
github-merge-queue bot pushed a commit that referenced this issue Sep 18, 2024
@jfecher
fix!: Infer globals to be u32 when used in a type (#6083)
78262c9 
# Description

## Problem\*

Resolves #6081
Resolves #6082

## Summary\*

Now that we check kinds explicitly we were erroring if globals weren't
already `u32` yet leading to a lot of existing code needing to be
changed.

If we change the exact equality to a unification check we can instead
infer the globals need to be a `u32` without requiring user code to be
changed.

This PR is still breaking since there were causes we didn't catch before
of invalid kinds being used in array lengths, e.g. `fn foo<let N: u8>(a:
[Field; N])` in one of our unit tests.

## Additional Context



## 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.
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Sep 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
Noir
Status: ✅ Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix!: Infer globals to be u32 when used in a type noir-lang/noir
1 participant
@jfecher