Event Manager handle_in_client hooks #1916
Conversation
| } | ||
| } | ||
|
|
||
| impl<Head, Tail, S> EventManagerHooksTuple<S> for (Head, Tail) |
There was a problem hiding this comment.
The old question: why don't we just do a vec with the hooks in it?
There was a problem hiding this comment.
Cannot constrain per-type/cannot look for specific trait impls/etc.
There was a problem hiding this comment.
Adding and removing hooks on the fly will be useful
There was a problem hiding this comment.
I just don't understand why one wouldn't implement a hook with dynamic behaviour instead. You aren't going to be generating hooks.
There was a problem hiding this comment.
No, because the generic is concretised in the call, not in the type. You'd need it to be concretised in the type for it to be a concrete dyn.
There was a problem hiding this comment.
There was a problem hiding this comment.
That's not the situation... The function being called must be generic. There's no concrete type A or B beforehand.
There was a problem hiding this comment.
Ah I get what you mean... The obvious solution would be not to give the hooks access to executor or fuzzer
There was a problem hiding this comment.
In any case, access to state and event manager should be fine tbh
| @@ -593,9 +629,6 @@ where | |||
| } => { | |||
| log::info!("Received new Testcase from {client_id:?} ({client_config:?}, forward {forward_id:?})"); | |||
|
|
|||
| if let Ok(meta) = state.metadata_mut::<TransferringMetadata>() { | |||
There was a problem hiding this comment.
so you ok with this?
@addisoncrump
there're two way to achieve what you want now.
1st way is to just make a hook that set this metadata (which i don't recommend)
2nd way is to make a hook that does what you want when new testcase comes, and return false then the subsequent testcase processing is skipped
No description provided.