Add instructions on fixing fuzz build - #953

Thanks!

I wonder if this is cause to revert #948 - cargo fuzz just doesn't work if you've compiled something else before?

Are there other benefits to a shared workspace considering everything has to be rebuilt under different flags anyway?

Good point... especially when fuzzers are a different monster.

I wonder if this is cause to revert #948 - cargo fuzz just doesn't work if you've compiled something else before?

rustc is smart enough to recompile everything if you override lto config. Failure to build fuzz does not depend on previous builds done, it forces a new build. Reverting the whole PR is not worth it I think. The PR introduced 2 changes:

1. Switches mozjs to upstream instead of the fork maintained by @notriddle
2. Makes fuzz part of the workspace.

I just verified that before my PR fuzz crate was not buildable with default llvm deps in Debian but was buildable in Archlinux. Now, with the PR merged it builds correctly in both Debian/Archlinux. We can revert the workspace sharing changes but mozjs switch from 1 should still stay.

Are there other benefits to a shared workspace considering everything has to be rebuilt under different flags anyway?

For regular devs who don't use fuzz, nothing should change. Because fuzz is not listed in default-members, all commands not explicitly stating the --package will ignore fuzz.
For people who want to work on fuzzers, sharing the workspace has better editor support. I did face an issue with rust-analyzer with default settings, it would complain that fuzz files are not part of the workspace and diagnostics stops working. The fix was opening the editor from fuzz dir which adds some friction. Another benefit is sharing the build cache. I am planning to introduce build manifest caching to github action + building fuzz dir during PR build. Building fuzz from scratch is slow but if previous manifest are cached it should be much quicker. This will allow catching issues like #947 before merge. It is technically possible to do the same with separate fuzz workspace but will require setting up different caches for root and fuzz workspaces.

mozjs switch from 1 should still stay.

Yes! I didn't think of that part.

Editor support is a good point. I had similar issues while working on dos-fuzzer.

I suppose then the current status is fine. Hopefully the issue can eventually be fixed in cargo-fuzz (or wherever in the stack).