Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update #[coverage(..)] attribute error messages to match the current implementation #134750

Merged
merged 6 commits into from
Dec 25, 2024

Conversation

Zalathar
Copy link
Contributor

The allowed positions for #[coverage(..)] attributes were expanded by #126721, but the corresponding error messages were never updated to reflect the new behaviour.

Part of #134749.

@Zalathar Zalathar added the A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) label Dec 25, 2024
@rustbot
Copy link
Collaborator

rustbot commented Dec 25, 2024

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 25, 2024
Comment on lines +74 to 89
/// "coverage attribute not allowed here"
#[derive(Diagnostic)]
#[diag(passes_coverage_not_fn_or_closure, code = E0788)]
pub(crate) struct CoverageNotFnOrClosure {
#[diag(passes_coverage_attribute_not_allowed, code = E0788)]
pub(crate) struct CoverageAttributeNotAllowed {
#[primary_span]
pub attr_span: Span,
#[label]
pub defn_span: Span,
/// "not a function, impl block, or module"
#[label(passes_not_fn_impl_mod)]
pub not_fn_impl_mod: Option<Span>,
/// "function has no body"
#[label(passes_no_body)]
pub no_body: Option<Span>,
/// "coverage attribute can be applied to a function (with body), impl block, or module"
#[help]
pub help: (),
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside: #[derive(Diagnostic)] is one of the most egregiously unpleasant compiler-internal APIs I've encountered. It's awful.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cf. #132181

Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I have a few questions, but these error messages do indeed look much more accurate than it was previously.

Comment on lines +117 to +119
.not_fn_impl_mod = not a function, impl block, or module
.no_body = function has no body
.help = coverage attribute can be applied to a function (with body), impl block, or module
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: does this specific wording account for this particular case:

// In situations where attributes can already be applied to expressions,
// the coverage attribute is allowed on closure expressions.
let _closure_tail_expr = {
    #[coverage(off)]
    || ()
};

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My intention here is to make the error message less verbose by implicitly treating closure expressions as a kind of “function”, whereas the error code documentation has the luxury of listing closures separately.

Is this a good idea? I'm not sure; I don't have much experience with user-facing error messages.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you mean. Should we perhaps say something like

help: coverage attribute can be applied to a function with body, impl block, module, and a few other kinds of attachees; see error code docs for more details

But yeah, I agree that it's not very helpful to exhaustively list them either.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this needs to be perfect (in this PR anyway).

Comment on lines 4 to 9
The coverage attribute can be applied to:
- Function and method declarations that have a body, including trait methods
that have a default implementation.
- Closure expressions, in situations where attributes can be applied to
expressions.
- `impl` blocks (inherent or trait), and modules.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: I know this is very verbose for an error message, but cf. previous commit's error messages like "not a function, impl block, or module" or "coverage attribute can be applied to a function (with body), impl block, or module", the docs here doesn't quite correspond to those messages, right?

Anyway, not a huge deal.

If you wish to apply this attribute to all methods in an impl or module,
manually annotate each method; it is not possible to annotate the entire impl
with a `#[coverage]` attribute.
The coverage attribute is a hint to the `-C instrument-coverage` flag to
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: maybe also emphasis on "hint"? I.e. hint to the compiler.

@jieyouxu jieyouxu assigned jieyouxu and unassigned compiler-errors Dec 25, 2024
@jieyouxu jieyouxu added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 25, 2024
@Zalathar Zalathar force-pushed the coverage-attr-errors branch from 94fa5b2 to e48fc62 Compare December 25, 2024 08:24
@Zalathar
Copy link
Contributor Author

Tweaked the wording of the error code docs (diff).

I think the other stuff is good enough to merge as a net improvement over the current docs; if someone has strong editorial opinions they can raise them in a follow-up thread or PR.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 25, 2024
Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! The wording can always be adjusted in a follow-up, but the improvements are already nice.

@@ -0,0 +1,116 @@
//! Tests where the `#[coverage(..)]` attribute can and cannot be used.
//@ reference: attributes.coverage.allowed-positions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @rust-lang/spec: should compiler reviewers ping you if a reference annotated test has expanded test coverage or modified test coverage?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually don't answer that (sorry), I'll add that as a question for the T-spec testing RFC.

Comment on lines +117 to +119
.not_fn_impl_mod = not a function, impl block, or module
.no_body = function has no body
.help = coverage attribute can be applied to a function (with body), impl block, or module
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this needs to be perfect (in this PR anyway).

@jieyouxu
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Dec 25, 2024

📌 Commit e48fc62 has been approved by jieyouxu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 25, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 25, 2024
Rollup of 3 pull requests

Successful merges:

 - rust-lang#134743 (Default to short backtraces for dev builds of rustc itself)
 - rust-lang#134750 (Update `#[coverage(..)]` attribute error messages to match the current implementation)
 - rust-lang#134751 (Enable LSX feature for LoongArch OpenHarmony target)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit db3404a into rust-lang:master Dec 25, 2024
6 checks passed
@rustbot rustbot added this to the 1.85.0 milestone Dec 25, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Dec 25, 2024
Rollup merge of rust-lang#134750 - Zalathar:coverage-attr-errors, r=jieyouxu

Update `#[coverage(..)]` attribute error messages to match the current implementation

The allowed positions for `#[coverage(..)]` attributes were expanded by rust-lang#126721, but the corresponding error messages were never updated to reflect the new behaviour.

Part of rust-lang#134749.
@Zalathar Zalathar deleted the coverage-attr-errors branch December 25, 2024 23:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants