-
Notifications
You must be signed in to change notification settings - Fork 13.5k
make path_statements lint machine applicable for statements with no effect #140830
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
base: master
Are you sure you want to change the base?
Conversation
r? @nnethercote rustbot has assigned @nnethercote. Use |
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.
Suggestion: since this is machine-applicable, can you add a test case for the suggestion where the stmt span constitutes of macro_call!();
, where macro_call!()
-the-expr-span might have a different syntax context?
(Unless this already exists, ofc)
@rustbot author |
4096867
to
ba2de32
Compare
|
ba2de32
to
6ababd0
Compare
}; | ||
} | ||
|
||
foo!(x); |
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.
@jieyouxu is this what you meant? Right now this is emitting the lint. Is the idea that this lint shouldn't be emitted the lint in this case or that it shouldn't be machine applicable?
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 somehow completely lost this notification, sorry about that. Now that I read my own comment #140830 (review) back, I think what I had in mind at the time was stuff like having a path statement that comes from a macro expansion from another crate, where I think I thought that a machine-applicable suggestion in that case wouldn't be very actionable.
... But that can be a follow-up or further adjusted as suitable, and does not need to block this PR at all.
The job Click to see the possible cause of the failure (guessed by this bot)
|
@rustbot ready |
r? @jieyouxu |
Requested reviewer is already assigned to this pull request. Please choose another assignee. |
|
||
macro_rules! foo { | ||
($e:expr) => { | ||
$e; |
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.
Note: I think you'll need a
//~^ ERROR: path statement with no effect
annotation here. I guess partly what I had in mind re. macros was also this case, where the suggestion is tied to removing $e;
, though arguably maybe it's the invocation foo!(x);
that should be removed.
Again, this is not blocking IMO.
Sorry about losing the notification, I just had some thoughts on the suggestion which are not blocking. Feel free to r=me after adding the missing error annotation. @rustbot author |
The motivation for this change is to make it easier to clean up code generated by c2rust, which tends to include a lot of unnecessary path statements.