使用kcov的锈蚀覆盖似乎不正确。

Question

当我使用codecov.io记录锈蚀项目的代码覆盖率时，覆盖率似乎不正确。

1. 未涵盖unwrap()函数和端括号。

​

1. 函数声明不包括在内。

​

这很奇怪。

我不能提供完整的复制项目。

我正在为Rust使用标准的TravisCI配置。这是我的.travis.yml：

language: rust
cache: cargo
dist: trusty
sudo: required

rust:
  - stable
  - beta
  - nightly

matrix:
  allow_failures:
    - rust: nightly

script:
  - cargo build --verbose --all
  - cargo test --verbose --all

after_success: |
  wget https://github.com/SimonKagstrom/kcov/archive/master.tar.gz &&
  tar xzf master.tar.gz &&
  cd kcov-master &&
  mkdir build &&
  cd build &&
  cmake .. &&
  make &&
  make install DESTDIR=../../kcov-build &&
  cd ../.. &&
  rm -rf kcov-master &&
  for file in target/debug/myproject-*[^\.d]; do mkdir -p "target/cov/$(basename $file)"; ./kcov-build/usr/local/bin/kcov --exclude-pattern=/.cargo,/usr/lib --verify "target/cov/$(basename $file)" "$file"; done &&
  bash <(curl -s https://codecov.io/bash)
  echo "Uploaded code coverage"

Answer 1

假设自从这个问题发布以来，Cargo和Travis的行为并没有发生明显的变化，这里有几件事情在起作用。

• 每当构建配置发生更改时，您的构建指纹就会发生变化，从而导致完全或部分重新构建，并为target中产生的二进制文件命名新的文件名。诚然，我不知道这种情况发生的确切时间和原因的复杂，我只是知道它会发生。事实上，对于我正在从事的项目，Cargo似乎对其中一个依赖项非常困惑，几乎每一次它都会强制进行重建。
• Travis的cache: cargo默认值非常愚蠢；它毫无例外地缓存所有的$CARGO_HOME和target。请注意，这与前者相结合还意味着这些缓存在没有绑定的情况下增长，因此您需要偶尔丢弃它们，或者使用更智能的缓存方案。
• for file in target/debug/myproject-*[^\.d]为所有myproject构建运行kcov，不管它是新构建的还是从Travis的构建缓存中运行的。当然，旧版本可能有不同的行号，因为它们是从不同(旧的)源构建的，而且覆盖范围可能不同。
• coverage.io通过在任何报表中包含一行红色来合并覆盖结果，除非它被任何(其他)报告所覆盖。如果来自不同报告的行号不匹配，或者即使其中一个报告包含超出EOF的行号，它也不会显示任何指示。事实上，就我所能找到的情况而言，它甚至没有显示包含/没有覆盖行号的二进制文件，即使它有这样的信息。您必须下载XML报告并手动解释它们才能看到这一点。

因此，那些裸露的线条可能不会(全部？)这是由于Rust编译二进制文件的方式，正如对问题的注释所示，但实际上可能指的是一个完全不同的(旧的)源文件。这在我们的项目中很明显过了一段时间后。

​

​

如果不是这么明显的话，那么最简单的方法就是抛弃Travis的构建缓存，强制进行重建。

由于增量构建实际上并不适用于我们的项目，所以我们使用的解决方案就是不像建议的这里那样让Travis缓存目标目录。取决于您的CI构建时间取决于增量构建，您可能被迫做一些更聪明的事情。