You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
structFoo<A,B>{field:B,}implFoo<u8,u8>{fnfoo(_self:Self) -> Field{1}}implFoo<u16,Field>{fnfoo(_self:Self) -> Field{2}}fnmain(){let field:Field = 0;let f = Foo{ field };assert(f.foo() == 2);}
Expected Behavior
The program to execute successfully
Bug
The program non-deterministically fails with:
error: No method named 'foo' found for type 'Foo<u8, Field>'
┌─ /.../short/src/main.nr:18:12
│
18 │ assert(f.foo() == 2);
│ -------
│
Aborting due to 1 previous error
From this we can see:
In, the original type of f, Foo<_, Field>, the type variable is being bound to u8 when seeing if the first method matches. When it does not match, the binding is not undone which causes the second method to fail to type check as well. If the binding was correctly undone, Foo<_, Field> would otherwise be compatible with the second method's object type Foo<u16, Field>.
The program only fails sometimes. This means the ordering of the methods in the method search is non-deterministic.
To Reproduce
Installation Method
None
Nargo Version
No response
Additional Context
No response
Would you like to submit a PR for this Issue?
No
Support Needs
No response
The text was updated successfully, but these errors were encountered:
# Description
## Problem\*
Resolves#3089. This issue also affected impl search which uses
`try_unify` to compare against every impl candidate. In some programs
this could cause invalid type bindings, eventually leading to various
mismatched/unexpected types panics during SSA.
## Summary\*
I've refactored `try_unify` to instead return a set of type bindings
which must be applied afterward if the function was successful. Each
caller of `try_unify` must do this manually now. Additionally,
`lookup_trait_implementation` must now juggle several sets of type
bindings and only commit to those that are not instantiation bindings
(otherwise the generic trait would be permanently bound to another
type), and even then only commit to them on success.
## Additional Context
## Documentation\*
Check one:
- [ ] 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 <[email protected]>
Aim
Expected Behavior
The program to execute successfully
Bug
The program non-deterministically fails with:
From this we can see:
f
,Foo<_, Field>
, the type variable is being bound tou8
when seeing if the first method matches. When it does not match, the binding is not undone which causes the second method to fail to type check as well. If the binding was correctly undone,Foo<_, Field>
would otherwise be compatible with the second method's object typeFoo<u16, Field>
.To Reproduce
Installation Method
None
Nargo Version
No response
Additional Context
No response
Would you like to submit a PR for this Issue?
No
Support Needs
No response
The text was updated successfully, but these errors were encountered: