Handle trait dispatch in the comptime interpreter #4925
Labels
enhancement
New feature or request
Comments
|
Relevant TODO for operator overloading here: noir/compiler/noirc_frontend/src/hir/comptime/interpreter.rs Lines 610 to 614 in b3a2c9c |
5 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Jun 25, 2024
# Description ## Problem\* ## Summary\* This PR replaces a panic with a nicer error plus a link to the relevant issue: #4925 ## 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. --------- Co-authored-by: jfecher <jake@aztecprotocol.com>
5 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Jul 2, 2024
# Description ## Problem\* Resolves #4925 ## Summary\* Implements trait dispatch in the interpreter - which includes operator overloading. ## Additional Context I've tried to share as much code as I can between the interpreter and monomorphization. Most of this PR is rather straightforward adapting code in the monomorphizer to use in the interpreter. The main new bit of code is a stack of `FunctionContext`s in the elaborator. I found at that when having a comptime block in the middle of a function, even a known trait would panic that it had no impl. This was because we previously delayed solving impls to the very end of a function when types were known. I've had to change this into a stack instead so that we can solve impls that were done within a comptime block at the end of that comptime block, just before interpreting so that they'd be defined. Similarly, the `type_variables` list also needed to be placed here since defaulting types can cause some trait constraints to succeed/fail without it. I settled on `function_context` for the name of this stack but am not sure if it fits the case where we have a stack of comptime contexts instead. Similarly, `ComptimeContext` also didn't make sense for the more common case of only having one of them for a function with no comptime blocks. ## 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
The comptime interpreter currently fails whenever a trait is needed.
Happy Case
The comptime interpreter should be able to handle trait dispatch, including operator overloading.
Project Impact
None
Impact Context
No response
Workaround
None
Workaround Description
No response
Additional Context
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: