-
Notifications
You must be signed in to change notification settings - Fork 199
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.
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
Build dependency graph between variables in name resolution #1122
Comments
@jfecher what is the status of this issue? |
Lowest hanging fruit to attempt to fix would be replacing suspicious usages of hashmap with something like indexmap |
@jfecher - "The above is not enough, we would need a dependency tree of structures, we could also use this in places where globals depend on other globals" |
Spoke with Jake; he says, ideally name resolution is split into smaller components and we build this dependency tree at the last step to be used in later passes. |
Can we re-tag this E-HIGH? I think it'd require a large rewrite of name resolution to first create the graph then follow its nodes to resolve names in that order. Edit: Retagged it as "Large" myself. Not sure what the precise difference is between Large and X-Large so I kept it on large. |
Choice is all good as long as it feels right. The Size field is used just as a subjective reference for now. |
# Description ## Problem\* Resolves #1122 ## Summary\* Adds a dependency graph to catch cases where structs will cyclically depend on one other. For example, the program: ```rs struct Foo { bar: Bar, } struct Bar { foo: Foo, } ``` Will now give the following error: ``` error: Dependency cycle found ┌─ /home/user/Code/Noir/noir/short/src/main.nr:6:1 │ 6 │ ╭ struct Bar { 7 │ │ foo: Foo, 8 │ │ } │ ╰─' 'Bar' recursively depends on itself: Bar -> Foo -> Bar │ ``` The error is still issued if these are split across separate modules. ## Additional Context Note that self-referential structs like `struct Foo { foo: Foo }` are not currently caught - we may need a separate check for this. This error is also only currently possible for cyclic struct dependencies, but once this is merged I'm going to expand this to more PRs to allow for globals and type aliases as well. This would implement #1734 as well as a similar feature to allow type aliases to reference other type aliases which is currently disallowed. ## Documentation\* Check one: - [x] No documentation needed. - [ ] Documentation included in this PR. - [ ] **[Exceptional Case]** 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: kevaundray <kevtheappdev@gmail.com>
Aim
Trying to write a program
Expected behavior
Noir should issue an error that nested arrays are currently unimplemented
Bug
The error is only issued sometimes when the program is compiled. This is because on some runs
Array
is resolved first and whenShouldError
is subsequently resolved, it can see all the fields ofArray
and will error that nested arrays are used. On other runs however,ShouldError
is resolved first and sees only an empty struct forArray
and thus does not issue an error. In this case, the program continues until monomorphization where it fails with an unreachable assert.To reproduce
Installation method
None
Nargo version
No response
@noir-lang/noir_wasm version
No response
@noir-lang/barretenberg version
No response
@noir-lang/aztec_backend version
No response
Additional context
No response
Submission Checklist
The text was updated successfully, but these errors were encountered: