Il mar 18 mar 2025, 07:16 Zhao Liu <zhao1....@intel.com> ha scritto: > > Would it be possible, or make sense, to move most of the code for > > field_exists inside .with_exist_check()? > > > > If so, the method would be like: > > pub fn with_exist_check<T, F>( > mut self, > _cb: F > ) -> Self > where > F: for<'a> FnCall<(&'a T, u8), bool>, > > Then the use case could be like: > > vmstate_struct!(HPETState, timers[0 .. num_timers], > &VMSTATE_HPET_TIMER, > BqlRefCell<HPETTimer>).with_exist_check<HPETState, _>(foo_field_check), > > Here we need to specify the structure type in with_exist_check, though it's > already specified in vmstate_struct as the first field. > > In this way, I understand with_exist_check() doesn't need phantom__() > trick. > > Instead, (after I dropped the few patches you mentioned,) now vmstate_of > & vmstate_struct could accept the optional "test_fn" field (luckily, at > least test_fn can still be parsed!), then the example would be: > > vmstate_struct!(HPETState, timers[0 .. num_timers], > &VMSTATE_HPET_TIMER, > BqlRefCell<HPETTimer>, foo_field_check) > > And in this way, phantom__() is necessary. > > So I think the main issue is the format, which do you prefer? >
For now I would leave out a generic field-exists check, and keep the implementation of vmstate_validate as you did it in v1. Once we look more in the builder concept we can think of adding also a VMStateField<T> (with a PhantomData<fn(&T) -> bool> inside) and add with_field_exists(). Paolo > Thanks, > Zhao > >
