-
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
Errors when comparing types #4635
Labels
bug
Something isn't working
Comments
5 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Mar 29, 2024
…4648) # Description ## Problem\* Resolves #4635 Resolves #4502 ## Summary\* This was more difficult to fix than it originally seemed. The main issue was between interactions with unbound type variables, type aliases, type rules for operators, and operator traits. Removing the "infer unbound type variables to be numeric" rule on operators causes a lot of stdlib code to break where it'd be unreasonable to have type annotations. This caused unbound type variables to be bound to the first object type whose impl it was checked against when calling verify trait impl. I eventually settled on just delaying the verify trait impl check for operators until the end of a function when more types are known. ## 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.
TomAFrench
pushed a commit
that referenced
this issue
Apr 3, 2024
…4648) # Description ## Problem\* Resolves #4635 Resolves #4502 ## Summary\* This was more difficult to fix than it originally seemed. The main issue was between interactions with unbound type variables, type aliases, type rules for operators, and operator traits. Removing the "infer unbound type variables to be numeric" rule on operators causes a lot of stdlib code to break where it'd be unreasonable to have type annotations. This caused unbound type variables to be bound to the first object type whose impl it was checked against when calling verify trait impl. I eventually settled on just delaying the verify trait impl check for operators until the end of a function when more types are known. ## 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.
nventuro
added a commit
to AztecProtocol/aztec-packages
that referenced
this issue
Apr 10, 2024
Doable now that noir-lang/noir#4635 is closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Aim
I'm running into multiple issues related to type inference. This is one of them, but I'm not entirely sure how to title this report because I don't really know what might be the underlying issue. I produced a small exaple that triggers it instead.
Ultimately this errors out with
error: Types in a binary operation should match, but found T and T
, which just seems wrong.Expected Behavior
Forgive the boiler-plate, hopefully it won't be too bad. It's just some standard utils for dealing with Fields and arrays as is done in the kernel circuits.
This errors out with:
which feels a bit non-sensical.
Bug
Honestly I'm not sure if the issue is my code, the error message or the compiler, but something does seem off here.
Installation Method
Compiled from source
Nargo Version
nargo version = 0.25.0 noirc version = 0.25.0+7deceac68414a6c24f2c4f9ecdd36ad6ac9752e3 (git version hash: 7deceac68414a6c24f2c4f9ecdd36ad6ac9752e3, is dirty: false)
The text was updated successfully, but these errors were encountered: