Support if-let guards in matches macros by using :guard matcher

[SpriteOvO]

Tracking issue #153104.

This PR replaces the original if $guard:expr with new matcher $guard:guard in macros matches! and assert_matches! to support the use of if-let guards syntax in these macros. This syntax is already stable in #141295 for match arms.

Please note that this PR directly applies :guard to macros that are already stable, so the support for if-let guards in these macros is instantly stable.

When using these macros that accept :guard, users will not be required to use nightly and enable #![feature(macro_guard_matcher)]. However, when defining macros with :guard, nightly and #![feature(macro_guard_matcher)] are still required. Therefore, I think a Crater run is needed.

cc @programmerjake
r? libs

[SpriteOvO]

Please note that this PR directly applies :guard to macros that are already stable, so the support for if-let guards in these macros is instantly stable.

When using these macros that accept :guard, users will not be required to use nightly and enable #![feature(macro_guard_matcher)]. However, when defining macros with :guard, nightly and #![feature(macro_guard_matcher)] are still required. Therefore, I think a Crater run is needed.

Alternatively, to be more safe, we only provide the :guard version of macros when users activate macro_guard_matcher, otherwise falling back to the original if $e:expr version. But I couldn't find a way to write something like #[cfg(unstable_feature = "macro_guard_matcher")] in stdlib.

[nia-e]

Hi - could you provide us some examples of where this might be a breaking change? We discussed this in the libs-api meeting but it wasn't quite clear what this might affect

[SpriteOvO]

rust/compiler/rustc_expand/src/mbe/macro_rules.rs

Lines 1716 to 1725 in 9128490

	NonterminalKind::Guard => {
	const TOKENS: &[&str] = &["`=>`", "`,`", "`{`"];
	match tok {
	TokenTree::Token(token) => match token.kind {
	FatArrow | Comma | OpenBrace => IsInFollow::Yes,
	_ => IsInFollow::No(TOKENS),
	},
	_ => IsInFollow::No(TOKENS),
	}
	}

@nia-e My main concern was in is_in_follow function, because the comment states it impacts future compatibility。 @fmease has also noted an unresolved question regarding this in the tracking issue. Let me quote it here and explain my thoughts alongside it:

• (fmease writing) Should { really be in the follow set? I'm not quite sure it should.
  • The condition of match guards can be an "unrestricted" expressions precisely because the guard can only be followed by => contrary to the conditions of if & while expressions and the iterator of for loops which are expressions without struct expressions.
  • So while if S {} successfully parses as an expression (namely as if (S) {}), macro matcher $g:guard {} currently rejects if S {} as input because it parses if (S {}) and looks for extra { } which aren't there of course.

I took some time to rethink it, given that the original intent of this matcher was just to simplify matching match-guards, rather than to allow users to extend the syntax with custom rules. And strictly according to MatchArmGuard, { is indeed not supposed to follow it. In that case, removing it might be better, or at least a conservative choice.

The requested Crater run was also based on the potential impacts mentioned above, plus, it’s instantly stable. If we decide to remove { from the follow-set, is the Crater run still needed? (Tbh, this is my first time requesting a Crater run, I'm not quite sure if such a change is worth a run)