rust/compiler/rustc_passes
Michael Goulet 9ce2a070b3
Rollup merge of #126682 - Zalathar:coverage-attr, r=lcnr
coverage: Overhaul validation of the `#[coverage(..)]` attribute

This PR makes sweeping changes to how the (currently-unstable) coverage attribute is validated:
- Multiple coverage attributes on the same item/expression are now treated as an error.
- The attribute must always be `#[coverage(off)]` or `#[coverage(on)]`, and the error messages for this are more consistent.
  -  A trailing comma is still allowed after off/on, since that's part of the normal attribute syntax.
- Some places that silently ignored a coverage attribute now produce an error instead.
  - These cases were all clearly bugs.
- Some places that ignored a coverage attribute (with a warning) now produce an error instead.
  - These were originally added as lints, but I don't think it makes much sense to knowingly allow new attributes to be used in meaningless places.
  - Some of these errors might soon disappear, if it's easy to extend recursive coverage attributes to things like modules and impl blocks.

---

One of the goals of this PR is to lay a more solid foundation for making the coverage attribute recursive, so that it applies to all nested functions/closures instead of just the one it is directly attached to.

Fixes #126658.

This PR incorporates #126659, which adds more tests for validation of the coverage attribute.

`@rustbot` label +A-code-coverage
2024-06-24 15:51:03 -04:00
..
src Rollup merge of #126682 - Zalathar:coverage-attr, r=lcnr 2024-06-24 15:51:03 -04:00
Cargo.toml Test and implement reachability for trait objects and generic parameters of functions 2024-03-14 14:10:45 +00:00
messages.ftl coverage: Always error on #[coverage(..)] in unexpected places 2024-06-24 20:15:03 +10:00