[DiagnosticsQoI] SR-3600: Better recovery for trying to name an initializer, deinitializer, or subscript

[matthewcarroll]

Add a diagnostic to remove the name of an initializer, deinitializer, or subscript. The identifier token is consumed and skipped to prevent the parser from emitting additional error messages.

Add tests to verify that the name is removed from initializers, deinitializers, and subscripts declared with a name.

https://bugs.swift.org/browse/SR-3600

class A { 
    init x() {} // error: initializers cannot have a name
    deinit y() {} // error deinitializers cannot have a name
    subscript z() -> Int { return 0 } // error subscripts cannot have a name
}

[matthewcarroll]

@CodaFi,

Would you mind reviewing this when you get a chance?

Thanks!

[jrose-apple]

This is interesting; because of the following colon, we ought to realize that it's parens that are missing, not a spurious name being added. I'm not sure this is a net improvement in this case.

Mind checking for a colon too? That would help initializers as well, though less so since init foo bar : Int could be a mistake for init foo(bar: Int) or init(foo bar: Int).

[matthewcarroll]

Maybe it’s preferable to treat init foo bar : Int as a mistake for int(foo bar : Int), since adding the parens would make the syntax valid. If so, I can restrict this diagnostic to require a following paren, and let the existing one handle that case (and do the same for subscripts). What do you think? (No problem if not. I can check for a colon following the identifier.)

[jrose-apple]

Your way seems reasonable. Thanks, Matthew!

[slavapestov]

Nitpick: we put else on the same line as } and generally avoid single-statement blocks

[slavapestov]

@swift-ci Please smoke test

[matthewcarroll]

@jrose-apple, @slavapestov,

I added a check for identifiers that are followed by a left paren, added some tests, and fixed the code style issues.

[jrose-apple]

Looks good. Thanks, Matthew!

[jrose-apple]

@swift-ci Please smoke test