Tracking issue for `..X`, and `..=X` (`#![feature(half_open_range_patterns)]`)

[Centril]

X.. was stabilized in #83918
..=X was stabilized in #102275
...X was removed in #68120

..X is tracked in #37854
X.. patterns in slices are currently gated via half_open_range_patterns_in_slices

This is a tracking issue for the feature gate #![feature(half_open_range_patterns)]. This feature provides half-open range patterns X.., ..X, ..=X, and ...X (last one is also deprecated like X...Y is, for spec & implementation simplicity). These correspond to the RangeFrom, RangeTo, RangeToInclusive, and RangeToInclusive expression forms, with the same syntaxes, respectively. 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). For implementations details, see #67258.

The implementation for the feature was introduced in #67258 and is also strongly related to #![feature(exclusive_range_pattern)] (X..Y) which is also required for X.. and ..X (as the RangeEnd::Exclusive syntax is used).

Steps:

• Once half_open_range_patterns have had some time to bake on nightly, write up an RFC specifying both exclusive_range_pattern and half_open_range and proposing their stabilization.

Unresolved questions:

• Possibly rethink the precedences, Operators in patterns have incorrect priorities #48501. We could ship without fixing this and leaving in the ambiguity errors. EDIT: Lang team considers this an orthogonal issue.
• The primary question to resolve is whether the lack of clarity around ..X for signed types being from -i32::MAX -- is that OK? Too confusing? EDIT: Lang team considers this acceptable, leaving open the possibility of future lints to help catch mistakes.

[Centril]

The implementation in #67258 landed on 2020-01-11. The PR was written by @Centril and reviewed by @oli-obk.

• Follow up with implementing Introduce X.., ..X, and ..=X range patterns #67258 (comment).

[Centril]

In #68120, which landed on 2020-01-11, the ...X syntax was prohibited, addressing #67258 (comment). Some diagnostics were also improved and tests were hardened. The PR was written by @Centril and reviewed by @oli-obk.

Everything should be well tested and implemented now. Once we have a new bootstrap compiler, we can start using it internally in the compiler, and eventually consider stabilization together with X..Y patterns.