go-fuzz: add fuzz.F

[josharian]

This is initial work towards #218.

DO NOT MERGE

I am sending it for discussion.

I am not entirely satisfied with this as it stands.

• It's a bit cumbersome.
• It's not well documented (yet).
• It requires starting a goroutine for every fuzz function invocation. Fixing this requires re-doing some of the layering and will be pretty disruptive.

Though it is not ready to merge, it is my hope that this will help move along the conversation. Feedback welcome as we all ponder more.

[dvyukov]

Good that you preserved backwards compatibility!

Re cumbersome, do you mean the large code template embed in the code? I am not too worried about strictly internal details that we are free to change at any time.

Re goroutine per test, the only reason for this is Skip/Goexit, right?

[dvyukov]

Re goroutine per test, the only reason for this is Skip/Goexit, right?

Have you considered panicing and recovering? I think the same could be used for Fail as well.

[josharian]

Re cumbersome, do you mean the large code template embed in the code?

Yes.

I am not too worried about strictly internal details that we are free to change at any time.

Fair enough.

Re goroutine per test, the only reason for this is Skip/Goexit, right?

Yes.

Have you considered panicing and recovering? I think the same could be used for Fail as well.

If the fuzz function calls recover, then we might never see the panic. This is the same reason that package testing uses a goroutine per invocation plus runtime.Goexit.

[dvyukov]

If the fuzz function calls recover, then we might never see the panic. This is the same reason that package testing uses a goroutine per invocation plus runtime.Goexit.

Recovering is kind of a corner case, but I guess sooner or later people will hit it and ask for proper handling. So handling it from day one is probably the right thing to do.

But we don't have to have a goroutine per test because of this, right?
We could create a worker goroutine and a reused channel for completion and as long as it does not Goexit, we reuse the same goroutine. If it exits, we create another one. This should give the same amortized performance as we have now.