9ce2a070b3
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 |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| messages.ftl | ||