Ah unfortunately wasmtime's fuzzing build is still failing, and I think it's due to this line because wasmtime's compile directory means the path to the fuzzers would be fuzz/fuzz_targets/...

Since this may not affect many other projects, would it be possible to have wasmtime-specific configuration in this case perhaps?

@alexcrichton

If I get right the latest coverage build logs from https://oss-fuzz-build-logs.storage.googleapis.com/index.html#wasmtime
It looks like the target is compiled ok, but the coverage report cannot find the referenced files, because we have only relative paths and not absolute paths.
cf rust-lang/cargo#5450
The cargo wrapper tries to hack this using export RUSTFLAGS="$RUSTFLAGS --remap-path-prefix src=$crate_src_abspath/src"
But regalloc.rs uses also bin directory for some source files
Hence we get the error AssertionError: File path "bin/fuzzing.rs" in coverage summary is outside source checkout. even if we have the file /out/src/regalloc.rs/bin/fuzzing.rs
There are more directories than regalloc.rs/bin which look problematic

So, I see 3 solutions

• adding as many --remap-path-prefix as there are directories with rust source code other than src for wasmtime
• Having the cargo wrapper do this automatically with something like a loop on find . -name "*.rs" | cut -d/ -f2 | uniq
• have cargo output absolute paths
  Do you see another one ?
  cc @richkadel do you have an idea about this ?

I think the best solution is probably integration into cargo fuzz itself which should have all the logic availble to it, but in the meantime would it be possible for wasmtime to use its own cargo wrapper for this?

in the meantime would it be possible for wasmtime to use its own cargo wrapper for this?

It is possible, but I am not sure what you mean.
Do you want the cargo wrapper to do find . -name "*.rs" | cut -d/ -f2 | uniq and sets multiple --remap-path-prefix ?
If so, why would you like it only for wasmtime ?

Sorry I don't know what the cut utility does so I'm not sure what that shell command would do. My thinking is that Wasmtime knows what paths are in play and how to pass through --remap-path-prefix so we can do something appropriate for Wasmtime if necessary. I'm not sure if it's possibly for wasmtime to bypass this wrapper, however.