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

NoMatchingImplFound in comptime code only #5615

Closed
jfecher opened this issue Jul 26, 2024 · 0 comments · Fixed by #5617
Closed

NoMatchingImplFound in comptime code only #5615

jfecher opened this issue Jul 26, 2024 · 0 comments · Fixed by #5617
Assignees
Labels
bug Something isn't working

Comments

@jfecher
Copy link
Contributor

jfecher commented Jul 26, 2024

Aim

use std::collections::umap::UHashMap;
use std::hash::BuildHasherDefault;
use std::hash::poseidon2::Poseidon2Hasher;

unconstrained fn main() {
    comptime {
        let mut map: UHashMap<u32, Field, BuildHasherDefault<Poseidon2Hasher>> =
            UHashMap::default();

        map.insert(1, 2);
    }
}

Expected Behavior

The code to execute.

Bug

error: No matching impl found for `B: BuildHasher<H>`
    ┌─ std/collections/umap.nr:406:26
    │
406 │         let mut hasher = self._build_hasher.build_hasher();
    │                          --------------------------------- No impl for `B: BuildHasher<H>`
    │

This error does not occur when the comptime block is removed, so there is a difference between how the monomorphizer and interpreter handle generics.

I've looked into this issue and determined it to be the following:

  • When the interpreter and elaborator call a function they bind monomorphization bindings at the beginning and undo them at the end.
  • In the interpreter, we call UHashMap::insert which binds (among other bindings) K'367 = u32, then calls UHashMap::try_resize, which calls UHashMap::len
  • UHashMap::len is on the same impl and binds the same K'367 = u32 on entrance, but then also unbinds it on exit.
  • Now when we return to insert and try_resize, our key type is unbound instead of being bound to a u32.
  • Monomorphization does not have this issue because it does not actually call functions in a call stack. Instead, it queues the need to monomorphize that function with the specified type. So the scenario where a finished function will undo the bindings of another does not occur because the monomorphizer's state is always wiped clean between each function.

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 Jul 26, 2024
@jfecher jfecher self-assigned this Jul 26, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Jul 26, 2024
github-merge-queue bot pushed a commit that referenced this issue Jul 29, 2024
# Description

## Problem\*

Resolves #5615

## Summary\*

Fixes a difference in how the interpreter and monomorphizer handle
generics - further explained in the linked issue.

## Additional Context

To fix this I saved the generics on each link in the call stack and
restored them after the function finishes. This wasn't good enough
however - doing this too early mean losing intermediate bindings in
`instantiation_bindings`. So I needed to add some `follow_bindings`
there as well. The `impl_bindings` all bind the trait impl to the trait
itself so follow_bindings there is unneeded.

## 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 Jul 29, 2024
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: Done
Development

Successfully merging a pull request may close this issue.

1 participant