-
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
Don't suggest a semicolon when one already exists #134247
base: master
Are you sure you want to change the base?
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @lcnr (or someone else) some time within the next two weeks. 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 (
|
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.
Hi 👋 please add a regression test to an appropriate subfolder of tests/ui
match source_map.span_to_snippet(span) { | ||
Ok(span_str) => !span_str.contains(';'), | ||
Err(_) => true, | ||
} |
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.
we probably want to change BlockTailInfo::tail_result_is_ignored
instead. Using spans for such checks does not work in case the error involves macro calls. The current check may also have issues if something like tail_expr ;
or tail_expr/* */;
or tail_expr<new-line>;
is used
I could imagine that we should either change tail_result_is_ignored
to an enum tracking why it's ignored or alternatively change LocalInfo::BlockTailTemp
to track whether the tail is an expr or a statement
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.
That makes sense! Thanks for the suggestion - I knew someone who knew more than me would steer me in a better direction. I'll look into that. 👍
@rustbot author |
@lcnr Sorry if you're not a good person to ask -- as far as I can tell, information about whether or not a statement/block ends with a semicolon is lost when |
If we currently end up erasing that information, making sure it's tracked somewhere during lowering is appropriate |
In cases where it can be confirmed that an expression with borrow conflicts is already followed by an expression, the compiler will no longer suggest adding a second semicolon.
This is my first time contributing to the compiler; I eagerly accept any feedback on improvements or how this could be done differently.
closes #133941