rust-lang / rust-lang/rust

`-C instrument-coverage` does not work with `crate-type = ["dylib"]` dependency on windows-msvc

Open
#124,372 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

A-code-coverage C-bug O-windows-msvc
Dominant language
Rust
Stars
119k
Forks
16.1k
PR merge metrics
PR metrics pending

Description

Repro
# Cargo.toml
[package]
name = "repro"
version = "0.1.0"
edition = "2021"

[dependencies]
dylib = { path = "dylib" }
// src\lib.rs
use dylib as _; // link dylib

pub fn double(x: i64) -> i64 {
    x * x
}

#[cfg(test)]
mod test {
    use crate::double;

    #[test]
    fn test_double() {
        assert_eq!(4, double(2))
    }
}
# dylib\Cargo.toml
[package]
name = "dylib"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["dylib"]
// dylib\src\lib.rs
// empty
# With powershell
$ $env:RUSTFLAGS="-C instrument-coverage"; cargo test --tests -v
   Compiling dylib v0.1.0 (C:\Users\taiki\projects\tmp\coverage_debugging\dylib)
     Running `rustc --crate-name dylib --edition=2021 dylib\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=183 --crate-type dylib --emit=dep-info,link -C prefer-dynamic -C embed-bitcode=no -C debuginfo=2 -C metadata=7a6a43aab10b14a1 --out-dir C:\Users\taiki\projects\tmp\coverage_debugging\target\debug\deps -C incremental=C:\Users\taiki\projects\tmp\coverage_debugging\target\debug\incremental -L dependency=C:\Users\taiki\projects\tmp\coverage_debugging\target\debug\deps -C instrument-coverage`
   Compiling repro v0.1.0 (C:\Users\taiki\projects\tmp\coverage_debugging)
     Running `rustc --crate-name repro --edition=2021 src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=183 --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --test -C metadata=ab884994c6371615 -C extra-filename=-ab884994c6371615 --out-dir C:\Users\taiki\projects\tmp\coverage_debugging\target\debug\deps -C incremental=C:\Users\taiki\projects\tmp\coverage_debugging\target\debug\incremental -L dependency=C:\Users\taiki\projects\tmp\coverage_debugging\target\debug\deps --extern dylib=C:\Users\taiki\projects\tmp\coverage_debugging\target\debug\deps\dylib.dll -C instrument-coverage`
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.40s
     Running `C:\Users\taiki\projects\tmp\coverage_debugging\target\debug\deps\repro-ab884994c6371615.exe`

running 1 test
test test::test_double ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

LLVM Profile Error: Runtime and instrumentation version mismatch : expected 9, but get -1879048144

I expected to see this happen: no "LLVM Profile Error"

Instead, this happened: the above "LLVM Profile Error"

If the dependency is not dylib, or if the dylib crate itself is tested alone, this problem does not occur.
This problem also occurs when both the repro crate and the dylib crate are dylib.

Originally reported in https://github.com/taiki-e/cargo-llvm-cov/issues/364 by @mdeering24.

Meta

rustc --version --verbose:

rustc 1.79.0-nightly (ef8b9dcf2 2024-04-24)
binary: rustc
commit-hash: ef8b9dcf23700f2e2265317611460d3a65c19eff
commit-date: 2024-04-24
host: aarch64-pc-windows-msvc
release: 1.79.0-nightly
LLVM version: 18.1.4

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the Windows-MSVC case using the root Cargo.toml, src/lib.rs, dylib/Cargo.toml, and dylib/src/lib.rs, with RUSTFLAGS set to -C instrument-coverage. Start by comparing the rustc invocations for the repro and dylib crates. Done means cargo test completes without the LLVM Profile Error for a dylib dependency.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
build-system, compilers, testing-qa
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.