Skip to content

Rollup of 5 pull requests #48860

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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
Contributor

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
Collaborator

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
Collaborator

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
Collaborator

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
# for free to join this conversation on GitHub. Already have an account? # 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