Faster defaults

[Shnatsel]

• Default to compiling in release mode with overflow checks and debug assertions enabled
  • Speeds up fuzzing ~10x
• Add command line option for controlling overflow checks
• Add command line option for forcing debug mode without optimizations

Resolves #230

[fitzgen]

Tests are failing because they look for bins at the target/debug path in various places, so they need to update to target/release.

Also, please add a test for the --dev (ne --debug) flag.

[Shnatsel]

I've fixed everything as requested. Will add a test for --dev shortly.

Do you have any ideas on how to clearly document that the default is --release --debug-assertions --overflow-checks? If I invoke --help it's not clear to me what the build mode will be if no parameters are passed.

Also, there are two changes that might be unexpected for end users:

• This changes the coverage numbers. Now that a great deal of branches can be optimized out, the reported coverage is much lower (~2000 instead of ~7500 edges for png crate).
• This changes the default location of the binary. If something was invoking the generated binary directly instead of via cargo fuzz run, that workflow will break.

Should we document this somewhere?

[Shnatsel]

Should be good to go now. Please take another look.

[fitzgen]

Also, there are two changes that might be unexpected for end users:

I'm personally not too concerned with either of these, but we can bump to 0.8.x to be safe. @Manishearth any opinion here?

Do you have any ideas on how to clearly document that the default is --release --debug-assertions --overflow-checks? If I invoke --help it's not clear to me what the build mode will be if no parameters are passed.

Perhaps in the before-help blurb for cargo fuzz run?

cargo-fuzz/src/main.rs

Lines 36 to 43 in 87c36a1

	const RUN_BEFORE_HELP: &'static str = "\
	The fuzz target name is the same as the name of the fuzz target script in
	fuzz/fuzz_targets/, i.e. the name picked when running `cargo fuzz add`.
	This will run the script inside the fuzz target with varying inputs until it
	finds a crash, at which point it will save the crash input to the artifact
	directory, print some output, and exit. Unless you configure it otherwise (see
	libFuzzer options below), this will run indefinitely.";

And I think we would also want a custom template for cargo fuzz build like how cargo fuzz run has:

cargo-fuzz/src/main.rs

Line 107 in 87c36a1

template(LONG_ABOUT_TEMPLATE),

This way we could include the same blurb for both subcommands's help messages.

[nagisa]

I'm personally not too concerned with either of these, but we can bump to 0.8.x to be safe.

There's not really a good reason to not bump a "breaking" version number for binaries once there are larger changes to the interface. I vote bump.

[Shnatsel]

I've added a blurb about default build flags to the help text of both cargo fuzz build and cargo fuzz run. I've also added a blurb about sanitizers to cargo fuzz build after-help text, mostly so that I wouldn't have to create yet another help template.

[Manishearth]

@fitzgen I don't consider these to require a new major version

[fitzgen]

Looks great, thanks @Shnatsel!

[frewsxcv]

but with debug assertions and overflow checks enabled

which code in this pr is responsible for enabling debug assertions with release mode by default?