Ekleog-NEAR

Just thinking: would it make sense, in addition to this, to have a `#[bolero::non_fuzz_test]` or similar macro? This’d allow the tests to be skipped when run with `BOLERO_LIBFUZZER_ARGS`, `CARGO_BOLERO_SELECT`, or...

That’d definitely be a much better solution, you’re right!

I thought about it some more, and it turns out that: - Linker-based test listing is hard - If a `#[bolero::test]` macro is added, we no longer need `bolero::check!()` -...

@camshaft What do you think of this solution? It sounds reasonable to me, the only drawback being that the test name is no longer as free as a unit test,...

Actually it wouldn’t solve the issue, I just tried making [a quick prototype](https://github.com/Ekleog-NEAR/bolero/commit/8f4e49d65c702a2f9858ed3c217b1cb52ce91243), and integration tests are run regardless of what filter is passed to `cargo test`, and are not...

So now that I understand Driver & DriverMode a bit: I think the way this would make most sense would be as an alternative Driver, like FuzzByteSliceDriver; that’d always run...

An example API for that would be: ```rust trait Driver { // ... type SequenceIterator(&'a mut self, allowed_lens: Range, gen: F) -> SequenceIterator

Actually, the thoughts I’ve put in https://github.com/camshaft/bolero/issues/90#issuecomment-1408742489 made me notice a possible alternative solution to here, though the question of why `DirectRng` is exposed stays. Maybe instead of having each...

Looking into the code… it probably is because libfuzzer execs itself again in order to implement -jobs? In which case I’m not entirely sure how this could be fixed besides...

I’m doing my best to review, but considering the size of the NEP I haven’t been able to complete within 24 hours. Will keep reviewing until I’m done with what...