-
Notifications
You must be signed in to change notification settings - Fork 59
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
AllocVar
implementation for Vec<T>
does not respect the setup mode
#17
Comments
Hmm it seems that this needs to be fixed by also requiring the length to be passed in somehow. One way is to change pub struct SliceWrapper<'a, I> { size: usize, slice: Option<&'a [I]> }
impl<...> SliceWrapper<...> {
fn empty(size: usize) -> Self {
Self {
size,
slice: None,
}
}
fn new(slice: &[I]) -> Self {
Self {
size: slice.len(),
slice: Some(slice),
}
}
} This latter always has has a defined length, and so we should always be able to unwrap it inside |
For the solution The feature is Should we do the second solution or wait for The second one would be more convenient because you can still use |
We can do both solutions, and for the array based one we can just implement it for common sizes (say, up to 32) |
I think we should take the approach of the wrapper struct for now, and remove the impl for |
Yes. Especially because the first one, |
* Fix pre_eq_reduce The pre_eq_reduce should directly reduce the value to the normal form rather than checking it. * fmt
In
alloc.rs
, we have the following implementation forVec<T>
:However, in the setup mode, assignments are missing, and we expect all executions of
f
to be wrapped, layer by layer, inside the closures ofnew_variable
. But the current implementation does not respect the setup mode. Instead, it runsf
and unwraps its result in the setup mode.There seems no easy solution. One may want to unwrap
f()
in eachA::new_variable
, butf
isFnOnce
, so callingf()?
inside the closure of each value in theVec
does not work.Now let me describe some thinking on how to solve it.
First, we can let
new_variable
break the "fourth wall" and check whether the ConstraintSystem being referenced is in the setup mode. This would allow it to treat the case in the setup mode differently.However, this is not enough, because it also needs to learn the size of the
Vec
. Iff()
cannot be run and unwrapped, there is no way for it to learn the size.So, this becomes a tangled situation. Going further, did we use this
Vec<T>
blanket implementation anywhere?The text was updated successfully, but these errors were encountered: