Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

As of 1.19 it is not possible to accurately measure unit test coverage #43410

Open
ctz opened this issue Jul 22, 2017 · 10 comments
Open

As of 1.19 it is not possible to accurately measure unit test coverage #43410

ctz opened this issue Jul 22, 2017 · 10 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.

Comments

@ctz
Copy link
Contributor

ctz commented Jul 22, 2017

1.19 prevents access to -Zno-landing-pads. I was using that to get accurate test coverage; without it all landing pads appear as uncovered code at the start and end of every function.

-Cpanic=abort is intended to be the stable replacement for -Zno-landing-pads but unfortunately that isn't supported for unit tests (apparently, because libtest requires unwinding support).

I'd like a way to do any of the following on stable:

  • restore no-landing-pads behaviour, or,
  • have panic=abort work for unit tests. Note that I don't much care that should_panic tests wouldn't work.

Is there some combination of cargo/rustc options that might achieve that?

@hanna-kruppe
Copy link
Contributor

#[should_panic] tests not working seems like a pretty big downside. Even if you don't care, the usefulness of coverage info seems entirely independent from whether you have #[should_panic] tests. Perhaps there's a better solution, e.g.,

  • Not having landing pads mess up coverage information (how do C++ tools solve this?)
  • Having a mode in libtest that runs tests in a child process, to be able to detect and handle panics

@nrc nrc added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 25, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 28, 2017
@kennytm
Copy link
Member

kennytm commented Jul 28, 2017

@rkruppe

C++ tools solve this by:

  1. In GCC, the generated *.gcno will encode whether an edge in the control-flow graph is exceptional or not, via the GCOV_ARC_FAKE flag. Coverage analyzer can choose to ignore these edges. LLVM's insert-gcov-profiling pass does not provide any of these information.

  2. clang uses instrprof (Implement support for LLVMs code coverage instrumentation #34701) instead of GCOV.

@marco-c
Copy link
Contributor

marco-c commented Jun 18, 2018

I guess we could try to add support for GCOV_ARC_FAKE in LLVM's gcov instrumentation.

@marco-c
Copy link
Contributor

marco-c commented Jul 5, 2018

The tracking issue for -Zprofile is #42524.

I think in the meantime, until this is fixed in LLVM, you can keep using -Zno-landing-pads as a workaround.

@richardwhiuk
Copy link

See also #55352 which proposes some alternative solutions here.

@ctz
Copy link
Contributor Author

ctz commented May 3, 2020

Note #43410 removes -Zno-landing-pads

@sanmai-NL
Copy link

@ctz: that's this issue, I think you mean a PR.

@ctz
Copy link
Contributor Author

ctz commented May 3, 2020

Derp. I meant #70175

@marco-c
Copy link
Contributor

marco-c commented May 5, 2020

Another workaround can be mozilla/grcov#427 (comment):

I managed to run tests for pyo3 in using -Cpanic=abort -Zpanic_abort_tests in RUSTFLAGS.
The doc tests were failing with that so adding an extra RUSTDOCFLAGS="-Cpanic=abort" fixes failures.

@rivy
Copy link

rivy commented May 5, 2020

Alternatively, pinning the rust version to nightly-2020-04-29 for code coverage also works, without altering flags or resultant coverage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

9 participants