Multipart Input support #1617
Multipart Input support #1617
Conversation
addisoncrump
force-pushed
the
multi-stream
branch
from
61ab9e0 to
cf90042
Compare
|
What's the status here? |
|
Sorry, still needs some work. Lots going on right now 🙂 I'll try to address this in the upcoming days. |
addisoncrump
force-pushed
the
multi-stream
branch
from
29c2c84 to
1db7d0a
Compare
|
|
||
| // without this, artificial bug is not found | ||
| // maybe interesting to try to auto-derive this, researchers! :) | ||
| count_set(count); |
There was a problem hiding this comment.
had to "cheat" here a little bit 😉
| /// related, or represent distinct parts of the input. | ||
| #[derive(Clone, Debug, Serialize, Deserialize)] | ||
| pub struct MultipartInput<I> { | ||
| parts: Vec<I>, |
There was a problem hiding this comment.
We could also have an input consisting of multipe different inputs at some point (but then we're basically doing grammar fuzzing?)
There was a problem hiding this comment.
Unfortunately it is really hard (read: impossible) for me to do dynamic types like this. I tried, but it just didn't work because the type constraints on mutator eventually need a concrete type. Users will simply need to wrap MultipartInput<I1> and MultipartInput<I2> or similar.
There was a problem hiding this comment.
Well we could do it the way we do Feedbacks, like, a MultiInput<I1, I2> and then a multiinput could have multiple multiinputs again (right?)
There was a problem hiding this comment.
The problem is the mutators -- it is not possible (to my knowledge) to have generic implementations for these with diverse input types. With this support as is, though, it shouldn't be too hard to implement what you're suggesting on a case-by-case basis.
This offers a basic implementation for multipart inputs with consistent sub-input types.