León Orell Valerian Liehr 8bd126cb18
Rollup merge of #120185 - Zalathar:auto-derived, r=wesleywiser
coverage: Don't instrument `#[automatically_derived]` functions

This PR makes the coverage instrumentor detect and skip functions that have [`#[automatically_derived]`](https://doc.rust-lang.org/reference/attributes/derive.html#the-automatically_derived-attribute) on their enclosing impl block.

Most notably, this means that methods generated by built-in derives (e.g. `Clone`, `Debug`, `PartialEq`) are now ignored by coverage instrumentation, and won't appear as executed or not-executed in coverage reports.

This is a noticeable change in user-visible behaviour, but overall I think it's a net improvement. For example, we've had a few user requests for this sort of change (e.g. #105055, https://github.com/rust-lang/rust/issues/84605#issuecomment-1902069040), and I believe it's the behaviour that most users will expect/prefer by default.

It's possible to imagine situations where users would want to instrument these derived implementations, but I think it's OK to treat that as an opportunity to consider adding more fine-grained option flags to control the details of coverage instrumentation, while leaving this new behaviour as the default.

(Also note that while `-Cinstrument-coverage` is a stable feature, the exact details of coverage instrumentation are allowed to change. So we *can* make this change; the main question is whether we *should*.)

Fixes #105055.
2024-01-24 15:43:12 +01:00
..
2023-12-24 20:08:57 +00:00

The tests in this directory are shared by two different test modes, and can be run in multiple different ways:

  • ./x.py test coverage-map (compiles to LLVM IR and checks coverage mappings)
  • ./x.py test coverage-run (runs a test binary and checks its coverage report)
  • ./x.py test coverage (runs both coverage-map and coverage-run)

Maintenance note

These tests can be sensitive to small changes in MIR spans or MIR control flow, especially in HIR-to-MIR lowering or MIR optimizations.

If you haven't touched the coverage code directly, and the tests still pass in coverage-run mode, then it should usually be OK to just re-bless the mappings as necessary with ./x.py test coverage-map --bless, without worrying too much about the exact changes.