Keeping something secret amongst 230 people is not an easy task. At some point the campaign has to become public, and it's better to do that in a planned, coordinated manner, than have it get leaked to the press.
> The unions require a certain amount of work experience to join and some have different levels of membership depending on how much work you do after joining.
To users who are following along who aren't familiar, this is not how all unions works. Presumably the commenter is talking about "trade unions" which is one of many types of unions.
If something is untyped in Sorbet, you can give it a type with `T.let`. So if the return value of function `foo` is untyped, but you have a high degree of confidence that it will return a `String`, you can do `ret = T.let(foo, String)`
I haven't, though I've thought about it. Most of the logic behind git2-rs (as far as I know) is written in C. While it's possible to run afl.rs on a Rust project that uses C code behind the scenes, I haven't ever attempted to get AFL instrumentation working on the underlying C code. I don't think it should be that difficult, I just haven't gotten around to it yet.
EDIT: I forgot to mention: It's possible to run AFL on uninstrumented code, it just won't be that smart about finding new code paths.
There's still a little more work to do though. Mainly, I want to compile AFL as a part of the workflow (see the afl-sys crate in the repo) so the user doesn't need to manually install AFL to use `cargo fuzz`.
In this particular instance, there's no reason to be shipping afl.rs in production code. It's just a tool that's meant for local development, testing environments, or maybe even part of a CI workflow.