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

Panic when monomorphizing HashMap code #4663

Open
jfecher opened this issue Mar 27, 2024 · 2 comments
Open

Panic when monomorphizing HashMap code #4663

jfecher opened this issue Mar 27, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@jfecher
Copy link
Contributor

jfecher commented Mar 27, 2024

Aim

use dep::std::collections::map::{ HashMap };
use dep::std::hash::BuildHasherDefault;
use dep::std::hash::pedersen::PedersenHasher;

fn main() {
    let map: HashMap<u64, u64, 10, BuildHasherDefault<PedersenHasher>> = HashMap::default();
    println(map == map);
}

Expected Behavior

The code to execute and print an empty hashmap.

Bug

The application panicked (crashed).
Message:  internal error: entered unreachable code: Failed to find trait impl during monomorphization. The failed constraint(s) are:
  BuildHasherDefault<PedersenHasher>: BuildHasher
Location: compiler/noirc_frontend/src/monomorphization/mod.rs:1022

This is a bug. We may have already fixed this in newer versions of Nargo so try searching for similar issues at https://github.com/noir-lang/noir/issues/.
If there isn't an open issue for this bug, consider opening one at https://github.com/noir-lang/noir/issues/new?labels=bug&template=bug_report.yml
exit 101

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
github-merge-queue bot pushed a commit that referenced this issue Mar 29, 2024
…#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.
TomAFrench pushed a commit that referenced this issue Apr 3, 2024
…#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.
@TomAFrench
Copy link
Member

New repo


use dep::std::collections::map::{ HashMap };
use dep::std::hash::BuildHasherDefault;
use dep::std::hash::poseidon::PoseidonHasher;

fn main() {
    let map: HashMap<u64, u64, 10, BuildHasherDefault<PoseidonHasher>> = HashMap::default();
    println(map == map);
}

@TomAFrench
Copy link
Member

This issue still exists on master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: 📋 Backlog
Development

No branches or pull requests

2 participants