-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Add suggestion to remove derive()
if invoked macro is non-derive
#109638
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @davidtwco (or someone else) soon. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
Hm. What do you mean by "sending the help message selectively", exactly? Though, in the cases this was known to be 100% correct, which I imagine selectivity might help, it would be nice if this had |
Sorry for the confusion, originally I'd thought the help message was invalid for some cases, but it looks to be fine. Based on tests all cases are valid. Though the |
It's now split between two errors, one to remove the invalid derive macro and one suggesting adding a new non-derive macro
This comment has been minimized.
This comment has been minimized.
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.
apologies for the delay in getting back to this, left some more comments
@@ -3,6 +3,14 @@ error: expected derive macro, found built-in attribute `inline` | |||
| | |||
LL | #[derive(inline)] | |||
| ^^^^^^ not a derive macro | |||
| | |||
help: Remove from the surrounding `derive()` |
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.
Could you add a new test case that has some of the trickier cases for this change? e.g. two derives, macro (to confirm it doesn't trigger), etc.
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.
As far as I can tell, this isn't valid. Was there something else you meant with macro?
macro_rules! foo {
() => {
Debug
};
}
#[derive(foo!())]
struct V;
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.
macro_rules! foo {
($foo:expr) => {
#[derive($foo)]
struct V;
};
}
Something more like this?
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'll approve this since it's been a little while and it's in a good state. Thanks for working on this.
@bors r+ |
…avidtwco Add suggestion to remove `derive()` if invoked macro is non-derive Adds to the existing `expected derive macro, found {}` error message: ``` help: remove the surrounding "derive()": --> $DIR/macro-path-prelude-fail-4.rs:1:3 | LL | #[derive(inline)] | ^^^^^^^ ^ ``` This suggestion will either fix the issue, in the case that the macro was valid, or provide a better error message if not Not ready for merge yet, as the highlighted span is only valid for trivial formatting. Is there a nice way to get the parent span of the macro path within `smart_resolve_macro_path`? Closes rust-lang#109589
☀️ Test successful - checks-actions |
Finished benchmarking commit (194a0bb): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
Adds to the existing
expected derive macro, found {}
error message:This suggestion will either fix the issue, in the case that the macro was valid, or provide a better error message if not
Not ready for merge yet, as the highlighted span is only valid for trivial formatting. Is there a nice way to get the parent span of the macro path within
smart_resolve_macro_path
?Closes #109589