Tracking issue for RFC 3637: Guard patterns

[traviscross]

This is a tracking issue for guard patterns (RFC 3637).
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

• Implement Guard Patterns down to THIR #129996
• Parse guard patterns #133424
• Lower Guard Patterns to HIR. #134989
• name resolution for guard patterns #140746
• gather_locals: only visit guard pattern guards when checking the guard #141275

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".