Change the disambiguation rule for function literals inside guards.

We now unconditionally prohibit function literals inside guards,
regardless of whether their bodies take the form `=> expression` or a
block.  This matches what was implemented in the parser.

See discussion in dart-lang/sdk#51482.

Author: stereotype441

accepted/future-releases/0546-patterns/feature-specification.md

@@ -1345,34 +1345,40 @@ var x = switch (obj) {
 
 A similar ambiguity exists with function expressions in initializer lists, if
 the constructor happens to be a factory constructor with `=>` for its body. We
-resolve the ambiguity similarly here:  When `=>` is encountered after `when` in
-a guard, if the code between forms a valid expression, then it is interpreted as
-such and the `=>` is treated as the separator between the guard and case body.
-*In the above example, we take the first interpretation.*
-
-This rules applies in all contexts where a guard can appear: switch statements,
-switch expressions, if-case statements, and if-case elements. *We could restrict
-this rule to guards only in switch expressions where the ambiguity arises, but
-that leads to a syntactic restriction that is context-sensitive and harder to
-learn. Since the rule is unusual enough as it is, we apply it as consistently as
-possible. Note that the related restriction on `=>` in constructor initializers
-applies even though generative constructors can't use `=>` for their body.*
-
-The rule is applied unconditionally even if the code after `=>` is not a valid
-body expression, as in:
+resolve the ambiguity similarly here: Inside the `expression` part of a
+`guardedPattern`, a function literal is not allowed, unless it is enclosed in
+grouping operators (parentheses, square brackets, or curly braces). *Therefore,
+if `=>` is encountered after `when` in a guard, the `=>` is treated as the
+separator between the guard and case body.  In the above example, we take the
+first interpretation.*
+
+This rule applies in all contexts where a guard can appear: switch statements,
+switch expressions, if-case statements, and if-case elements.  It also applies
+to all function expressions, whether their body is `=>` followed by an
+expression, a block delimited by curly braces. *We could restrict this rule to
+guards only in switch expressions where the ambiguity arises, and to function
+literals using `=>`. But that leads to a syntactic restriction that is
+context-sensitive and harder to learn. Since the rule is unusual enough as it
+is, we apply it as consistently as possible. Note that the related restriction
+on constructor initializers applies regardless of whether the function literal
+uses `=>` or a block, even though generative constructors can't use `=>` for
+their body.*
+
+*The rule is applied unconditionally even if the code after `=>` is not a valid
+body expression, as in:*
 
 ```dart
 var x = switch (obj) {
   _ when (a) => b => c
 };
 ```
 
-Here, we treat the guard expression as `(a)`, which leads the body to be `b =>
-c` which isn't a valid expression and produces a compile-time error.
+*Here, we treat the guard expression as `(a)`, which leads the body to be `b =>
+c` which isn't a valid expression and produces a compile-time error.*
 
-If you want a guard expression that ends in a function expression (which is
+*If you want a guard expression that ends in a function expression (which is
 quite unlikely), you can avoid the `=>` being captured as the case separator by
-parenthesizing the function:
+parenthesizing the function:*
 
 ```dart
 var x = switch (obj) {