Skip to content
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

Rollup of 6 pull requests #68052

Closed
wants to merge 18 commits into from
Closed

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Jan 9, 2020

Successful merges:

Failed merges:

r? @ghost

Thomasdezeeuw and others added 18 commits January 6, 2020 15:41
This feature adds `X..`, `..X`, and `..=X` patterns.
Introduce `X..`, `..X`, and `..=X` range patterns

Tracking issue: rust-lang#67264
Feature gate: `#![feature(half_open_range_patterns)]`

---------------------------

In this PR, we introduce range-from (`X..`), range-to (`..X`), and range-to-inclusive (`..=X`) patterns.
These correspond to the `RangeFrom`, `RangeTo`, and `RangeToInclusive` expression forms introduced with the same syntaxes. The correspondence is both syntactic and semantic (in the sense that e.g. a `X..` pattern matching on a scrutinee `s` holds exactly when `(X..).contains(&s)` holds).

---------------------------

Noteworthy:

- The compiler complexity added with this PR is around 10 lines (discounting new tests, which account for the large PR size).

- `...X` is accepted syntactically with the same meaning as `..=X`. This is done primarily to simplify and unify the implementation & spec. If-and-when we decide to make `X...Y` a hard error on a new edition, we can do the same for `...X` patterns as well.

- `X...` and `X..=` is rejected syntactically just like it is for the expression equivalents. We should perhaps make these into semantic restrictions (cc @petrochenkov).

- In HAIR, these half-open ranges are represented by inserting the max/min values for the approprate types. That is, `X..` where `X: u8` would become `X..=u8::MAX` in HAIR (note the `..=` since `RangeFrom` includes the end).

- Exhaustive integer / char matching does not (yet) allow for e.g. exhaustive matching on `0usize..` or `..5usize | 5..` (same idea for `isize`). This would be a substantially more invasive change, and could be added in some other PR.

- The issues with slice pattern syntax has been resolved as we decided to use `..` to mean a "rest-pattern" and `[xs @ ..]` to bind the rest to a name in a slice pattern.

- Like with rust-lang#35712, which provided `X..Y` range patterns, this is not yet backed up by an RFC. I'm providing this experimental implementation now to have something concrete to discuss. I would be happy to provide an RFC for this PR as well as for rust-lang#35712 to finalize and confirm the ideas with the larger community.

Closes rust-lang/rfcs#947.

---------------------------

r? @varkor cc @matthewjasper @oli-obk

I would recommend reviewing this (in particular HAIR-lowering and pattern parsing changes) with whitespace changes ignored.
…sKalbertodt

Add HashSet::get_or_insert_owned

This is an extension for tracking issue rust-lang#60896. The more-general `get_or_insert_with` has potential for misuse, so we might remove it, but I think `get_or_insert_owned` covers most use cases.
…tboats

Relax the Sized bounds on Pin::map_unchecked(_mut)

Fixes rust-lang#67669.
…r=alexcrichton

Export public scalar statics in wasm

Fixes rust-lang#67453

I am not sure which export level statics should get when exporting them in wasm. This small change fixes the issue that I had, but this might not be the correct way to implement this.
Change -Z time event naming scheme and make them generic activities

I made the `-Z time-passes` only events (which encodes argument in the event id) use a `extra_verbose_generic_activity` function which does not emit self-profiling events.

r? @michaelwoerister
cc @wesleywiser
Recognise riscv64 in compiletest

Otherwise tests can't run, fails with "Cannot determine Architecture from triple"
@Centril
Copy link
Contributor Author

Centril commented Jan 9, 2020

@bors r+ p=6 rollup=never

@bors
Copy link
Contributor

bors commented Jan 9, 2020

📌 Commit f2716e3 has been approved by Centril

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jan 9, 2020
@Centril Centril added the rollup A PR which is a rollup label Jan 9, 2020
@bors
Copy link
Contributor

bors commented Jan 9, 2020

⌛ Testing commit f2716e3 with merge 8011f83...

bors added a commit that referenced this pull request Jan 9, 2020
Rollup of 6 pull requests

Successful merges:

 - #67258 (Introduce `X..`, `..X`, and `..=X` range patterns)
 - #67358 (Add HashSet::get_or_insert_owned)
 - #67935 (Relax the Sized bounds on Pin::map_unchecked(_mut))
 - #67975 (Export public scalar statics in wasm)
 - #67988 (Change -Z time event naming scheme and make them generic activities)
 - #68006 (Recognise riscv64 in compiletest)

Failed merges:

 - #67806 (Extract `rustc_ast_passes`, move gating, & refactor linting)

r? @ghost
@bors
Copy link
Contributor

bors commented Jan 9, 2020

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 9, 2020
@Centril Centril closed this Jan 9, 2020
@Centril Centril deleted the rollup-xlktwp3 branch January 9, 2020 19:39
# 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-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants