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.

Sign up for GitHub

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

Jump to bottom

Impl search can return an impl instead of erroring when multiple compatible impls are found #4653

Closed
jfecher opened this issue Mar 27, 2024 · 0 comments · Fixed by #4662
Closed

Impl search can return an impl instead of erroring when multiple compatible impls are found #4653

jfecher opened this issue Mar 27, 2024 · 0 comments · Fixed by #4662
Labels
bug Something isn't working

Comments

@jfecher
Copy link
Contributor

jfecher commented Mar 27, 2024

Aim

Found while testing #4648.

This can be found when e.g.

let foo = dep::std::unsafe::zeroed();
println(foo == foo);  // Eq ?T

// or since `i` is generic in loops:
for i in 0 .. 10 {
    println(i < 10);  // Ord ?T  for some numeric T
}

Expected Behavior

The compiler to issue an error saying type annotations are needed.

Bug

The compiler chooses the first impl which matches. Before #4648 this was impl bool for Eq and impl u8 for Ord just due to how these were ordered in the stdlib.

To Reproduce

Project Impact

None

Impact Context

No response

Workaround

None

Workaround Description

No response

Additional Context

No response

Installation Method

None

Nargo Version

No response

NoirJS Version

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response
@jfecher jfecher added the bug Something isn't working label Mar 27, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Mar 27, 2024
@jfecher jfecher mentioned this issue Mar 27, 2024
Merged
5 tasks
This was referenced Mar 27, 2024
Merged
Closed
github-merge-queue bot pushed a commit that referenced this issue Mar 29, 2024
@jfecher
fix: Impl search no longer selects an impl if multiple are applicable (…
0150600 
…#4662)

# Description

## Problem\*

Resolves #4653

## Summary\*

If the object type is an unbound type variable, impl search currently
just chooses the first available matching impl instead of erroring that
type annotations are needed or similar. This can lead to confusing
situations where the type chosen is chosen just because it was the first
impl in the stdlib to be defined. This PR prevents that.

## Additional Context

This PR depends on #4648 and
should be merged after.

~~The `hashmap` test is currently failing because the `H: Hasher`
constraint on its `Eq` implementation ~~is actually unsolvable since `H`
isn't mentioned in the hashmap type at all~~. It is solvable since it is
meantioned in `B`, although solving it so far has lead to errors during
monomorphization. Previously it was fine since H was unbound and the
first/only impl was just always chosen. Now I'll need to change or
remove H to fix it.~~

This PR is now ready to review. I've been debugging a bug with
monomorphizing some HashMap code for a little while but it turns out the
bug is also present in master. So I'm considering it a separate issue:
#4663

## 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.
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Mar 29, 2024
TomAFrench pushed a commit that referenced this issue Apr 3, 2024
@jfecher @TomAFrench
fix: Impl search no longer selects an impl if multiple are applicable (…
d251309 
…#4662)

# Description

## Problem\*

Resolves #4653

## Summary\*

If the object type is an unbound type variable, impl search currently
just chooses the first available matching impl instead of erroring that
type annotations are needed or similar. This can lead to confusing
situations where the type chosen is chosen just because it was the first
impl in the stdlib to be defined. This PR prevents that.

## Additional Context

This PR depends on #4648 and
should be merged after.

~~The `hashmap` test is currently failing because the `H: Hasher`
constraint on its `Eq` implementation ~~is actually unsolvable since `H`
isn't mentioned in the hashmap type at all~~. It is solvable since it is
meantioned in `B`, although solving it so far has lead to errors during
monomorphization. Previously it was fine since H was unbound and the
first/only impl was just always chosen. Now I'll need to change or
remove H to fix it.~~

This PR is now ready to review. I've been debugging a bug with
monomorphizing some HashMap code for a little while but it turns out the
bug is also present in master. So I'm considering it a separate issue:
#4663

## 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
Assignees
No one assigned
Labels
bug Something isn't working
Projects
Noir
Archived in project
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix: Impl search no longer selects an impl if multiple are applicable noir-lang/noir
1 participant
@jfecher