Allow leading dot syntax for StaticParserError

[hamishknight]

Convert StaticParserError into a struct, and define the diagnostics in a DiagnosticMessage where Self == StaticParserError extension. This allows us to use leading dot syntax to pass a StaticParserError anywhere a DiagnosticMessage is expected. Also, do the same for StaticParserFixIt.

To compute the diagnostic ID, we can (ab)use #function to pick up the name of the property

[hamishknight]

/Users/ec2-user/jenkins/workspace/swift-syntax-PR-macOS/branch-main/swift-syntax/Sources/SwiftParser/Diagnostics/ParseDiagnosticsGenerator.swift:442:5: error: type of expression is ambiguous without more context
    exchangeTokens(
    ^~~~~~~~~~~~~~~

:( wonder what swift version CI is using

[hamishknight]

Looks like the CI is using Swift 5.5, which should be fine as it should have SE-0299, but it seems the 5.5 constraint system is barfing when a closure is involved (works on 5.6 though). Adding a generic parameter to exchangeTokens & removeToken should work around the issue.

[ahoppen]

Neat idea 🤩 I’ve got a couple of additional suggestion/ideas:

• Could you add a test case that checks the diagnostic ID for one StaticParserError? I would like to see how the diagnostic ID looks like (basically making sure it contains no parentheses)
• I find it harder to find diagnostic messages in the new extension but I think that’s resolved by formatting the diagnostic messages as single lines, e.g.

public static var allStatmentsInSwitchMustBeCoveredByCase: Self { .init("all statements inside a switch must be covered by a 'case' or 'default' label") }

• I think we can do the same for StaticParserFixIt.

[hamishknight]

Could you add a test case that checks the diagnostic ID for one StaticParserError? I would like to see how the diagnostic ID looks like (basically making sure it contains no parentheses)

We already have one :)

I find it harder to find diagnostic messages in the new extension but I think that’s resolved by formatting the diagnostic messages as single lines, e.g.

Hmm, I definitely prefer the current formatting. Putting them on a single line means that each diagnostic message starts at a different column (depending on how long the var name is), which make it hard to read IMO. It also makes it extra hard for people with smaller screens, e.g:

I think we can do the same for StaticParserFixIt

👍

[hamishknight]

Bleh, the 5.5 compiler really seems to struggle with these:

/Users/ec2-user/jenkins/workspace/swift-syntax-PR-macOS/branch-main/swift-syntax/Sources/SwiftParser/Diagnostics/ParseDiagnosticsGenerator.swift:192:43: error: missing argument label 'fromProtocol:' in call
              newNode: Syntax(TokenSyntax.identifier("`\(invalidIdentifier.text)`", leadingTrivia: invalidIdentifier.leadingTrivia, trailingTrivia: invalidIdentifier.trailingTrivia))
                                          ^
                              fromProtocol: 
/Users/ec2-user/jenkins/workspace/swift-syntax-PR-macOS/branch-main/swift-syntax/Sources/SwiftParser/Diagnostics/ParseDiagnosticsGenerator.swift:268:12: error: type 'FixIt.Change' has no member 'remove'
          .remove(unexpected: unexpected)
          ~^~~~~~

going to add back the StaticParserFixIt overloads on FixIt, which we can drop once 5.6 is the minimum required Swift version.

[hamishknight]

@swift-ci please test