-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Rollup of 5 pull requests #48860
Merged
Merged
Rollup of 5 pull requests #48860
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
This crate moves the compiler's error reporting to using the `termcolor` crate from crates.io. Previously rustc used a super-old version of the `term` crate in-tree which is basically unmaintained at this point, but Cargo has been using `termcolor` for some time now and tools like `rg` are using `termcolor` as well, so it seems like a good strategy to take! Note that the `term` crate remains in-tree for libtest. Changing libtest will be a bit tricky due to how the build works, but we can always tackle that later. cc rust-lang#45728
Programmers used to working in some other languages (such as Python or Go) might expect to be able to destructure values with comma-separated identifiers but no parentheses on the left side of an assignment. Previously, the first name in such code would get parsed as a single-indentifier pattern—recognizing, for example, the `let a` in `let a, b = (1, 2);`—whereupon we would have a fatal syntax error on seeing an unexpected comma rather than the expected semicolon (all the way nearer to the end of `parse_full_stmt`). Instead, let's look for that comma when parsing the pattern, and if we see it, momentarily make-believe that we're parsing the remaining elements in a tuple pattern, so that we can suggest wrapping it all in parentheses. We need to do this in a separate wrapper method called on the top-level pattern (or `|`-patterns) in a `let` statement, `for` loop, `if`- or `while let` expression, or match arm rather than within `parse_pat` itself, because `parse_pat` gets called recursively to parse the sub-patterns within a tuple pattern. Resolves rust-lang#48492.
In accordance with rust-lang#46997, I've replaced: > The returned line is not the invocation of the line! macro itself [...] By > The returned line is *not necessarily* the line of the `line!` invocation itself [...]
Just like `line!` documentation, I've replaced: > The returned column is not the invocation of the `column!` macro itself By > The returned column is *not necessarily* the line of the `column!` invocation itself See rust-lang#46997.
…ion_of_tuples, r=estebank in which parentheses are suggested for should-have-been-tuple-patterns ![destructure_suggest_parens](https://user-images.githubusercontent.com/1076988/36638335-48b082d4-19a7-11e8-9726-0d043544df2f.png) Programmers used to working in some other languages (such as Python or Go) might expect to be able to destructure values with comma-separated identifiers but no parentheses on the left side of an assignment. Previously, the first name in such code would get parsed as a single-indentifier pattern—recognizing, for example, the `let a` in `let a, b = (1, 2);`—whereupon we would have a fatal syntax error on seeing an unexpected comma rather than the expected semicolon (all the way nearer to the end of `parse_full_stmt`). Instead, let's look for that comma when parsing the pattern, and if we see it, make-believe that we're parsing the remaining elements in a tuple pattern, so that we can suggest wrapping it all in parentheses. We need to do this in a separate wrapper method called on a "top-level" pattern, rather than within `parse_pat` itself, because `parse_pat` gets called recursively to parse the sub-patterns within a tuple pattern. ~~We could also do this for `match` arms, `if let`, and `while let`, but we elect not to in this patch, as it seems less likely for users to make the mistake in those contexts.~~ Resolves rust-lang#48492. r? @petrochenkov
rustc: Migrate to `termcolor` crate from `term` This crate moves the compiler's error reporting to using the `termcolor` crate from crates.io. Previously rustc used a super-old version of the `term` crate in-tree which is basically unmaintained at this point, but Cargo has been using `termcolor` for some time now and tools like `rg` are using `termcolor` as well, so it seems like a good strategy to take! Note that the `term` crate remains in-tree for libtest. Changing libtest will be a bit tricky due to how the build works, but we can always tackle that later. cc rust-lang#45728
…atsakis Add functionality for gating feature flags on epochs ; rejigger epoch lints fixes rust-lang#48794 r? @nikomatsakis
…ntation, r=joshtriplett Modify part of `line!` documentation. In accordance with rust-lang#46997, I've replaced: > The returned line is not the invocation of the line! macro itself [...] By > The returned line is *not necessarily* the line of the `line!` invocation itself [...]
…mentation, r=joshtriplett Modify part of `column!` documentation. Just like `line!` documentation, I've replaced: > The returned column is not the invocation of the `column!` macro itself By > The returned column is *not necessarily* the line of the `column!` invocation itself See rust-lang#46997.
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
label
Mar 9, 2018
@bors r+ p=10 |
📌 Commit b65b171 has been approved by |
bors
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
Mar 9, 2018
☀️ Test successful - status-appveyor, status-travis |
This was referenced Mar 9, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
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.
termcolor
crate fromterm
#48588, Add functionality for gating feature flags on epochs ; rejigger epoch lints #48801, Modify part ofline!
documentation. #48856, Modify part ofcolumn!
documentation. #48857