Skip to content

Inconsistent handling of #[coverage(..)] attributes that are malformed or misplaced #126658

Closed
@Zalathar

Description

@Zalathar

(Note: The coverage attribute is currently unstable; see #84605.)

While writing tests for #[coverage(..)] for #84605, I encountered various inconsistencies in diagnostics for using the attribute with incorrect syntax or on inappropriate items.

For example:

  • Bare #[coverage] is silently permitted in various situations, even though it should never be legal.
    • E.g. on modules, on impl blocks, on trait, and on impl Trait.
  • Using name-value syntax #[coverage = "off"] results in different error messages than other kinds of incorrect syntax, and sometimes results in multiple errors for the same attribute.
    • The error message also claims that bare #[coverage] is permitted, which is incorrect.
  • Using #[coverage(off)] or #[coverage(on)] on things other than functions/methods/closures sometimes results in an error, and sometimes only a warning.
    • It seems to be an error on inappropriate items, but only a warning on (non-closure) expressions, even though it would have no effect in either case.
  • There is no diagnostic for attaching multiple otherwise legal coverage annotations to a single item, even though it's unclear which one would prevail.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-code-coverageArea: Source-based code coverage (-Cinstrument-coverage)A-diagnosticsArea: Messages for errors, warnings, and lintsC-bugCategory: This is a bug.D-confusingDiagnostics: Confusing error or lint that should be reworked.D-inconsistentDiagnostics: Inconsistency in formatting, grammar or style between diagnostic messages.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions