Disable lto and explicit profile

[ijc]

Fixes #384.

I included both the disable LTO bit and the capability to support custom profiles. I'm happy to drop either one.

I'm concerned about how custom profiles will interact with these uses of build.release and build.dev:

cargo-fuzz/src/project.rs

Lines 233 to 235 in a608970

	if !build.release || build.debug_assertions || build.careful_mode {
	rustflags.push_str(" -Cdebug-assertions");
	}

and

cargo-fuzz/src/project.rs

Lines 241 to 251 in a608970

	// If release mode is enabled then we force 1 CGU to be used in rustc.
	// This will result in slower compilations but it looks like the sancov
	// passes otherwise add `notEligibleToImport` annotations to functions
	// in LLVM IR, meaning that *nothing* can get imported with ThinLTO.
	// This means that in release mode, where ThinLTO is critical for
	// performance, we're taking a huge hit relative to actual release mode.
	// Local tests have once showed this to be a ~3x faster runtime where
	// otherwise functions like `Vec::as_ptr` aren't inlined.
	if !build.dev {
	rustflags.push_str(" -C codegen-units=1");
	}

I'm unclear how to determine the right condition for a custom profile -- might be a reason to drop that bit.

[fitzgen]

I'm concerned about how custom profiles will interact with ...

I haven't looked at the actual PR yet, but I think we can make it so that we have a build.profile that is ultimately a String¹ and we can match on that value and set these flags only for the profiles and special cases we are aware of. For custom profiles, the user can always specify their own custom flags in the profile definition, and that might be the best we can offer here.

Footnotes

1. Or an enum Profile { Dev, Release, Custom(String) } or something. ↩

[fitzgen]

Thanks! LGTM with the nitpick below addressed.

[fitzgen]

Can you do this in the above .arg(..).arg(..) method chain, since it is added in both dev and non-dev, and then just have an if without an else for adding the !build.dev extra args? That would cut down on duplication a little.

[ijc]

I think this is a comment on the first commit, at this commit the two config options are slightly different since they contain the profile name profile.release.lto=false vs profile.dev.lto=false which I think makes it hard to directly refactor as you suggest.

But this actually changes how you suggest in later commits as part of making the profile support more generic and we end up with:

        cmd.args([
            &format!("--profile={profile}"),
            "--config",
            &format!("profile.{profile}.debug=true"),
            "--config",
            &format!("profile.{profile}.lto=false"),
        ]);

[ijc]

@fitzgen I'm not sure what is wrong with CI.

I ran the cargo +nightly-2024-09-18 test locally (since that is the version CI picked up) and it passes.

[fitzgen]

I've retriggered CI, just in case it was some weird ephemeral issue (haven't really had those issues as far as I can remember)