Coverage spreads to nested cargo invocation

[kjetilkjeka]

I'm working with code running on GPUs using cuda. I'm experimenting with writing the code being run on the GPU in rust and use a buildscript (build.rs) to invoke cargo with --target nvptx64-nvidia-cuda. I then embed the resulting assembly (ptx) into the final executable using the include_str! macro. The nvptx64 target needs to be build as a #![no_std] target using -Zbuild-std.

It seems like the cargo invocation made in the buildscript for building the GPU assembly is also being called with the -C instrument-coverage flag. This is a problem as it is not supported on #![no_std] targets. It seems to persist even when clearing the RUSTFLAGS env variable or explicitly setting -C instrument-coverage=off for the nested cargo invocation.

Is this the preferred behavior or would it be better to require the nested cargo invocation to explicitly ask for coverage for it to be generated? Are there any known workarounds?

[taiki-e]

I don't know the details of your build script, so I can't provide any specific suggestions, but any of the following may work:

• Passing --target option avoids applying RUSTFLAGS to the build script.
• Passing --coverage-target-only option uses CARGO_TARGET_{target}_RUSTFLAGS instead of RUSTFLAGS. (see fix: add --coverage-target-only, to use rustflags only for target #167 for more)

[kjetilkjeka]

Passing --target option avoids applying RUSTFLAGS to the build script.

This doesn't help. It seems like it avoids applying RUSTFLAGS for the build.rs compilation. But the problem is actually the cargo invocation which is performed in the build.rs file and the coverage stuff seems to spreads to that command.

Passing --coverage-target-only option uses CARGO_TARGET_{target}_RUSTFLAGS instead of RUSTFLAGS

This seems to be the correct workaround, but it unfortunately doesn't work alone. I did some digging and it seems like even though the coverage stuff doesn't make it into RUSTFLAGS it still makes it into CARGO_ENCODED_RUSTFLAGS. That is the reason the coverage stuff is spread to the consecutive cargo invocation. If I use std::process::Command::env_remove with CARGO_ENCODED_RUSTFLAGS when invoking cargo it seems to work with --coverage-target-only.

That means I have found a workaround so feel free to close the issue unless you feel like the nested cargo invocation needs first class support. It is admittedly not a common use case so it is totally understandable for this to be a "wontfix". Also let me know if there's anything I can do to help out.

[taiki-e]

unless you feel like the nested cargo invocation needs first class support

Considering that CARGO_ENCODED_RUSTFLAGS is an environment variable set by cargo for build scripts, it seems impossible to provide first class support for this on the cargo-llvm-cov side alone.