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
use std::collections::umap::UHashMap;use std::hash::BuildHasherDefault;use std::hash::poseidon2::Poseidon2Hasher;
unconstrained fnmain(){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
The text was updated successfully, but these errors were encountered:
# 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.
Aim
Expected Behavior
The code to execute.
Bug
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:
UHashMap::insert
which binds (among other bindings)K'367 = u32
, then callsUHashMap::try_resize
, which callsUHashMap::len
UHashMap::len
is on the same impl and binds the sameK'367 = u32
on entrance, but then also unbinds it on exit.insert
andtry_resize
, our key type is unbound instead of being bound to au32
.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
The text was updated successfully, but these errors were encountered: