Initialization fails in workspaced directories

[mgattozzi]

If I have a directory like this:

my_first_binary
my_second_binary
Cargo.toml

Where Cargo.toml only contains something like this:

[workspace]
members = [
    "my_first_binary",
    "my_second_binary"
]

Then initialization fails on an unwrap of None on an Option (though it doesn't say which one). It would be nice if cargo-fuzz could worked with workspaced projects so that it has one folder with targets for all binaries in the workspace.

[Manishearth]

Yeah, you have to cd into a crate to do it for now.

[whitequark]

Seems similar to #15.

[Ekleog]

FWIW, in have a workspace that looks like this, cargo fuzz list also fails

[workspace]
members = [ "smtp-message", "smtp-message/fuzz",
            "smtp-server", "smtp-server/fuzz",
            "smtp-queue", "smtp-queue-fs",
            "benches" ]

It fails with error: could not read the manifest file: "[...]/yuubind/fuzz/Cargo.toml" caused by: No such file or directory (os error 2), which isn't the same error message as the one reported above, but I just wanted to send this message so that this issue could track the “cargo fuzz basically doesn't work with workspaces” issue :)

[casey]

I'm not sure if this should still be open, I was able to get a fuzz target working with the rest of my workspace. (Although due to rust-lang/cargo#4897 I have to pass RUSTFLAGS='-C debuginfo=1'.)

[joshua-auchincloss]

Can this be reviewed as cargo fuzz init still does not work with workspaced projects

[iqdecay]

Can confirm that cargo fuzz init does not work in workspaced projects.

[jonboh]

For anyone getting here, after the merge of #349 this is solved.
There isn't still a release available with this change, but you can workaround building cargo-fuzz locally.