-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Conversation
Some of these cases are also implicitly checked by other tests, but it's helpful to also explicitly list them in the main test.
rustbot has assigned @compiler-errors. Use |
/// "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: (), | ||
} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cf. #132181
There was a problem hiding this 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.
.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 |
There was a problem hiding this comment.
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)]
|| ()
};
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
94fa5b2
to
e48fc62
Compare
There was a problem hiding this 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
.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 |
There was a problem hiding this comment.
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).
@bors r+ rollup |
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
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.
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.