Improve diagnostic for unnamed closure parameter

[AnthonyLatsis]

Issue Kind

Bad Diagnostic Produced

Source Code

test { ([X]) in }

Description

New parser:

error: unexpected code '[X]' in parameter clause
test { ([X]) in }
        ^~~

Old parser:

warning: unnamed parameters must be written with the empty name '_' [parameter_unnamed_warn]
test { ([X]) in }
        ^
        _:

This is a special case. More generally, the old parser is capable of diagnosing this kind of closure parameter production gracefully when all of the following are true:

• An argument name cannot be parsed (link)
• A type can be parsed per Parser::canParseType(), and said type is followed by ,, ), or = (link)

---

Related to #2331.

[ahoppen]

Tracked in Apple’s issue tracker as rdar://118109912

[michaelleejl]

Could I be assigned the issue? Thanks!

[ahoppen]

To clarify: The C++ parser used to emit a warning for this and is changed in swiftlang/swift#70065 to instead emit an error. The new parser should also emit an error but one that is nicer than the currently emitted unexpected code '[X]' in parameter clause

[AppAppWorks]

I was able to get this new test passed,

func testRecovery185() {
  // <rdar://1181099123>
  assertParse(
    """
    test { (1️⃣[X]) in }
    """,
    diagnostics: [
      DiagnosticSpec(message: "expected identifier and ':' in parameter", fixIts: ["insert identifier and ':'"]),
    ],
    fixedSource: """
      test { (<#identifier#>: [X]) in }
      """
  )
}

by making the following modifications in Parsers.parseFunctionParameter,

- let colon = self.consume(if: .colon)
- let type: RawTypeSyntax?
- if colon != nil {
-  type = self.parseType(misplacedSpecifiers: misplacedSpecifiers)
- } else {
-  type = nil
- }

+ var colon = self.consume(if: .colon)
+ var type: RawTypeSyntax? = self.parseType(misplacedSpecifiers: misplacedSpecifiers)
+ if type?.raw.kind != .missingType {
+  if colon == nil {
+    colon = missingToken(.colon)
+  }
+ } else if colon == nil {
+  type = nil
+ }

In the existing code, a missing colon would short-circuit type parsing, leaving any type following it to be parsed as UnexpectedSyntaxNodes as in test { ([X]) in }.
In the modified code, the parser will continue to parse the type regardless of whether colon is found.
If a type is found as in test { ([X]) in }, colon will be marked missing if it was not found;
If there is no type found and colon was not found, type will be set to nil to reinstate the short-circuiting logic in the existing code.