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 |
||
|---|---|---|
| .. | ||
| back | ||
| debuginfo | ||
| mir | ||
| traits | ||
| assert_module_sources.rs | ||
| base.rs | ||
| codegen_attrs.rs | ||
| common.rs | ||
| errors.rs | ||
| lib.rs | ||
| meth.rs | ||
| mono_item.rs | ||
| size_of_val.rs | ||
| target_features.rs | ||