Fix some grammar inconsistencies for the '..' range notation. #21374
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @nick29581 (rust_highfive has picked a reviewer for you, use r? to override) |
Grammar changes:
* allow 'for _ in 1..i {}' (fixes rust-lang#20241)
* allow 'for _ in 1.. {}' as infinite loop
* prevent use of range notation in contexts where only operators of high
precedence are expected (fixes rust-lang#20811)
Parser code cleanup:
* remove RESTRICTION_NO_DOTS
* make AS_PREC const and follow naming convention
* make min_prec inclusive
dgrunwald
force-pushed
the
range-notation-fixes
branch
from
7fb1be2
to
db013f9
Compare
|
Rebased onto the big |
|
@dgrunwald ok reading this now. On the face of it, it looks much nicer than the previous patch. I haven't had time to play with it yet, but I take it that this means that |
|
I think I am happy with this version, all things considered. A good compromise. |
|
looks fine to me too. |
|
⌛ Testing commit db013f9 with merge 90224cf... |
|
💔 Test failed - auto-mac-64-nopt-t |
|
@bors: retry |
|
⌛ Testing commit db013f9 with merge e9285f9... |
bors
added a commit
that referenced
this pull request
Jan 23, 2015
This PR is intended as alternative to #20958. It fixes the same grammar inconsistencies, but does not increase the operator precedence of `..`, leaving it at the same level as the assignment operator. For previous discussion, see #20811 and #20958. Grammar changes: * allow `for _ in 1..i {}` (fixes #20241) * allow `for _ in 1.. {}` as infinite loop * prevent use of range notation in contexts where only operators of high precedence are expected (fixes #20811) Parser code cleanup: * remove `RESTRICTION_NO_DOTS` * make `AS_PREC` const and follow naming convention * make `min_prec` inclusive r? nikomatsakis
bors
added a commit
that referenced
this pull request
Jan 29, 2015
Note: Do not merge until we get a newer snapshot that includes #21374 There was some type inference fallout (see 4th commit) because type inference with `a..b` is not as good as with `range(a, b)` (see #21672). r? @alexcrichton
bors
added a commit
that referenced
this pull request
Jan 29, 2015
Note: Do not merge until we get a newer snapshot that includes #21374 There was some type inference fallout (see 4th commit) because type inference with `a..b` is not as good as with `range(a, b)` (see #21672). r? @alexcrichton
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is intended as alternative to #20958. It fixes the same grammar inconsistencies, but does not increase the operator precedence of
.., leaving it at the same level as the assignment operator.For previous discussion, see #20811 and #20958.
Grammar changes:
for _ in 1..i {}(fixes range syntax doesn't work with non-literal endpoints in for statements #20241)for _ in 1.. {}as infinite loopParser code cleanup:
RESTRICTION_NO_DOTSAS_PRECconst and follow naming conventionmin_precinclusiver? nikomatsakis