Allow .. to be parsed as let initializer by RedDocMD · Pull Request #105701 · ru...
source link: https://github.com/rust-lang/rust/pull/105701
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Allow .. to be parsed as let initializer #105701
Conversation
.. and ..= are valid expressions, however when used in a let statement
it is not parsed.
Fixes #105634
Collaborator
rustbot commented Dec 14, 2022
|
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) soon. Please see the contribution instructions for more information. |
added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Member
Nilstrieb commented Dec 14, 2022
|
Thank you for your pull request! A small tip: you can write "Fixes #105634" in your description to clarify that you're fixing the issue and also because GitHub will then automatically close the issue when the PR is merged. |
Contributor
lcnr commented Dec 14, 2022
|
r? compiler |
added the needs-fcp This change is insta-stable, so needs a completed FCP to proceed. label
src/test/ui/parser/issue-105634.rs
Outdated Show resolved
let expr = if self.token.is_range_seperator() { |
||
self.parse_prefix_range_expr(None) |
||
} else { |
||
self.parse_prefix_expr(None) |
||
}; |
Contributor
CAD97
Dec 14, 2022
My immediate expectation would be that parse_prefix_expr includes parse_prefix_range_expr. Are there any cases where we use parse_prefix_expr and we want prefix range expressions to be an error? If yes, make sure there's a test for that; if no, then it's probably better to move the range separator check/parse inside parse_prefix_expr.
I've not looked at this code much, but the reason it might matter is for other operator precedence reasons; e.g. what's the correct result of parsing +..1 or 1+..1.
Contributor
Author
RedDocMD
Dec 16, 2022
I think this separation of prefix range parsing from other prefix expr parsing is done to prevent expressions such as -..1 or !..1 from being parsed. Other unary operators can be stacked (may not be typeable), but you cannot have .. or ..= after a unary operator.
Contributor
cjgillot commented Dec 25, 2022
|
Thanks! |
Contributor
bors commented Dec 25, 2022
Commit added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
labels
Contributor
bors commented Dec 25, 2022
Testing commit Contributor
bors commented Dec 25, 2022
|
|
Test successful - Collaborator
rust-timer commented Dec 25, 2022
|
Finished benchmarking commit (300aa90): comparison URL. Overall result:
|
| mean | range | count | |
|---|---|---|---|
Regressions  (primary) |
- | - | 0 |
| Regressions (secondary) |
- | - | 0 |
Improvements  (primary) |
-0.4% | [-0.4%, -0.4%] | 1 |
| Improvements (secondary) |
-0.5% | [-1.0%, -0.4%] | 12 |
| All (primary) |
-0.4% | [-0.4%, -0.4%] | 1 |
Max RSS (memory usage)
This benchmark run did not return any relevant results for this metric.
Cycles
Results
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Successfully merging this pull request may close these issues.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK