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"