Skip to content
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 18 commits into from
Mar 9, 2018
Merged

Rollup of 5 pull requests #48860

merged 18 commits into from
Mar 9, 2018

Conversation

alexcrichton and others added 18 commits March 7, 2018 07:30
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.
@rust-highfive
Copy link
Collaborator

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 9, 2018
@Manishearth
Copy link
Member Author

@bors r+ p=10

@bors
Copy link
Contributor

bors commented Mar 9, 2018

📌 Commit b65b171 has been approved by Manishearth

@bors 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
@bors
Copy link
Contributor

bors commented Mar 9, 2018

⌛ Testing commit b65b171 with merge 2079a08...

bors added a commit that referenced this pull request Mar 9, 2018
Rollup of 5 pull requests

- Successful merges: #48527, #48588, #48801, #48856, #48857
- Failed merges:
@bors
Copy link
Contributor

bors commented Mar 9, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: Manishearth
Pushing 2079a08 to master...

@bors bors merged commit b65b171 into rust-lang:master 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants