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.

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

Typevariables can be bound while searching for methods #3089

Closed
jfecher opened this issue Oct 10, 2023 · 0 comments · Fixed by #3697
Closed

Typevariables can be bound while searching for methods #3089

jfecher opened this issue Oct 10, 2023 · 0 comments · Fixed by #3697
Assignees
Labels
bug Something isn't working compiler frontend `noirc_frontend` crate

Comments

@jfecher
Copy link
Contributor

jfecher commented Oct 10, 2023

Aim

struct Foo<A, B> {
    field: B,
}

impl Foo<u8, u8> {
    fn foo(_self: Self) -> Field { 1 }
}

impl Foo<u16, Field> {
    fn foo(_self: Self) -> Field { 2 }
}

fn main() {
    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

@jfecher jfecher added bug Something isn't working compiler frontend `noirc_frontend` crate P-MEDIUM labels Oct 10, 2023
@jfecher jfecher self-assigned this Oct 10, 2023
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Oct 10, 2023
github-merge-queue bot pushed a commit that referenced this issue Dec 7, 2023
# 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]>
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working compiler frontend `noirc_frontend` crate
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant