-Zcoverage is unimplemented

[weiznich]

I've tried to use the cranlift rust backend for a project that records code coverage for tests. For this I run the following command:

RUSTFLAGS="-Zcodegen-backend=cranelift" cargo +nightly llvm-cov test -j 1

which resulted in the following error:

   Compiling proc-macro2 v1.0.78
error: -Zcoverage is unimplemented

stmt Coverage::CounterIncrement(0)
fn main() -> () {
    let mut _0: ();
// … more MIR 

I expected that this would likely not work. I was just surprised that there is no issue for this yet, so I filled that one.

[bjorn3]

LLVM's coverage infrastructure is LLVM specific and the exact data format even changes between LLVM versions.

https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#format-compatibility-guarantees

There are no backwards or forwards compatibility guarantees for the raw profile format. Raw profiles may be dependent on the specific compiler revision used to generate them. It’s inadvisable to store raw profiles for long periods of time.

Implementing coverage support in cg_clif would be possible, but it will not be compatible with llvm-cov. And it will require writing a replacement for the LLVM profiler runtime and getting rustc to use this replacement.

[weiznich]

Thanks for your response. As already written before I did not expect this to work.

I think the problematic part here is that -Ccoverage is a option that's supported by a stable compiler, which somewhat makes this format/option more official from my point of view.

Maybe a short term solution would be to just change the message so that it does not say anymore that it's unimplemented but not supported or something like that? Maybe even with a bit more context outlining that this is a llvm specific feature?

[bjorn3]

-Cllvm-args is also supported on stable, yet we don't guarantee anything about it either. We can't anyway as LLVM doesn't make any stability promises about which flags it supports. (Clang flags don't always directly map to LLVM flags and some LLVM flags are not exposed by clang at all.)

Maybe a short term solution would be to just change the message so that it does not say anymore that it's unimplemented but not supported or something like that? Maybe even with a bit more context outlining that this is a llvm specific feature?

Done