-
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
Identify when a stmt could have been parsed as an expr #60188
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@varkor I thought that we wanted to make sure the parser was unambiguous. Some of these cases can be identified in the parser itself, but some require checks in the type checker or elsewhere. At that point the options are either only accept some of these operations but not others, which could look arbitrary, or have a more advanced parser/evaluator, which aiui is out of the question. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
r? @varkor |
There are some expressions that can be parsed as a statement without a trailing semicolon depending on the context, which can lead to confusing errors due to the same looking code being accepted in some places and not others. Identify these cases and suggest enclosing in parenthesis making the parse non-ambiguous without changing the accepted grammar.
Sorry for the delay; I will get to this soon. |
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 made a few comments, but I still need to think about this some more.
I agree that the grammar should be unambiguous, but I was under the impression some of these cases were not ambiguous; they were just tricky to detect. Maybe it's reasonable to close these issues as diagnostic issues, but I think there should be an issue somewhere keeping track of this until a deliberate decision has been made. |
That is indeed true. If you look at https://github.com/rust-lang/rust/pull/60188/files#diff-11be04506fe70f5f173b5fdf7f294ad7 you can see the full list of unambiguous operations, but I wouldn't want to have some constructs work, and some not in an almost arbitrary manner. |
ping @varkor :) |
@bors r+ |
📌 Commit 54430ad has been approved by |
Identify when a stmt could have been parsed as an expr There are some expressions that can be parsed as a statement without a trailing semicolon depending on the context, which can lead to confusing errors due to the same looking code being accepted in some places and not others. Identify these cases and suggest enclosing in parenthesis making the parse non-ambiguous without changing the accepted grammar. Fix rust-lang#54186, cc rust-lang#54482, fix rust-lang#59975, fix rust-lang#47287.
Rollup of 8 pull requests Successful merges: - #59348 (Clean up and add tests for slice drop shims) - #60188 (Identify when a stmt could have been parsed as an expr) - #60234 (std: Derive `Default` for `io::Cursor`) - #60618 (Comment ext::tt::transcribe) - #60648 (Skip codegen for one UI test with long file path) - #60671 (remove unneeded `extern crate`s from build tools) - #60675 (Remove the old await! macro) - #60676 (Fix async desugaring providing wrong input to procedural macros.) Failed merges: r? @ghost
There are some expressions that can be parsed as a statement without
a trailing semicolon depending on the context, which can lead to
confusing errors due to the same looking code being accepted in some
places and not others. Identify these cases and suggest enclosing in
parenthesis making the parse non-ambiguous without changing the
accepted grammar.
Fix #54186, cc #54482, fix #59975, fix #47287.