Tracking issue for RFC 3637: Guard patterns

[traviscross]

This is a tracking issue for XXX.

The feature gate for the issue is #![feature(guard_patterns)].

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Accept an RFC.
  • Guard Patterns rfcs#3637
• Implement in nightly.
• Add documentation to the dev guide.
  • See the instructions.
• Add documentation to the reference.
  • See the instructions.
• Add formatting for new syntax to the style guide.
  • See the nightly style procedure.
• Stabilize.
  • See the instructions.

Unresolved Questions

• Should we allow mismatched bindings when possible in pattern disjunctions?
• How should we refer to "guard patterns"?

### Implementation history
- [ ] https://github.com/rust-lang/rust/pull/129996
- [ ] https://github.com/rust-lang/rust/pull/133424
- [ ] https://github.com/rust-lang/rust/pull/134989

cc @max-niederman

[safinaskar]

Current wording of this RFC (3637) contradicts policy introduced in RFC 3531 ( https://rust-lang.github.io/rfcs/3531-macro-fragment-policy.html ). RFC 3637 says that old macro fragment specifier for patterns should be named pat_no_top_guard, but RFC 3531 says that it should be named something like pat_2021

[traviscross]

No, what's here is fine. The policy says we use the edition number only when "no better semantically meaningful name could be found".