[SR-11574] Using `try` instead of `throws` should have a better diagnostic

[beccadax]

Previous ID	SR-11574
Radar	None
Original Reporter	@beccadax
Type	Improvement
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Improvement, DiagnosticsQoI, Parser, StarterBug
Assignee	@vguerra
Priority	Medium

md5: 4b1deee143c591cfa05263856f246b0c

Issue Description:

Suppose you absentmindedly type try in a function declaration when you meant to type throws. Swift's diagnostic in this situation is not very good:

Welcome to Apple Swift version 5.1.1 (swiftlang-1100.0.274.1 clang-1100.0.33.9).
Type :help for assistance.
  1> func foo() try {}
error: repl.swift:1:11: error: consecutive statements on a line must be separated by ';'
func foo() try {}
          ^
          ;

A message along the lines of "expected throwing specifier; did you mean throws?" with a fix-it would provide a much nicer experience.

To implement this, you would find the place(s) in the parser where we parse the "throws" keyword and attempt to parse the "try" keyword there if "throws" fails. If you parse it, you should emit the diagnostic and then have the compiler pretend that it parsed "throws" to recover from the error. We're already doing this for "throw", so you might just be able to add "try" to the same code path.

[vguerra]

hello brentdax (JIRA User),

I had a quick look at this and managed to add a diagnostic for the use-case you described (vguerra@dc4e173), but while writing the test I realised that the same can happen on usage of try instead of throws on function types:

let t : () try -> Int

Does it make sense to have such diagnostic for this case as well?

[theblixguy]

What about generalising it - instead of parsing a “try”, you can parse an identifier?

[beccadax]

@vguerra Yes, that seems like a sensible extension of the idea. I haven’t thought through if there would be any complications, though.

@theblixguy I don’t think just any identifier is the right thing to do here because that could just as easily be some other kind of mistake—(Int) String probably means you forgot the ->, not that you meant to write throws. try is a special case because it’s a related keyword, so it’s easy to imagine someone mixing the two up. (Like, um, I did, about ten minutes before I filed this bug. 😉 )

[vguerra]

hi @theblixguy,

yes, it could be generalized to trigger the diagnostic for any identifier, one only has to check if that identifier is a where, which would mark the start of the generic-where-clause.

[vguerra]

but yeah .. as brentdax (JIRA User) mentions, the idea is to catch the mistyping of `throws`.

brentdax (JIRA User), i'll look then into the function-type case, as the parsing happens somewhere else (`parseDeclVar`).

[theblixguy]

Yeah, I didn't mean any identifier (sorry). I mean, if we have something like

func foo() <whatever> {}
func foo() -> <whatever> {}

and <whatever> is not one of [where, throws, tuple, etc] then we can emit this diagnostic. For example, one could write

func foo() throwz {} // typo
func foo() -> throwz {} // typo

which I think should also cause this diagnostic to be emitted.

[rintaro]

Typo correction for keywords might be a good idea, but that's beyond the scope of this specific issue.
@theblixguy Could you file another JIRA issue for that?

[vguerra]

PR for this ticket merged : #27647

[beccadax]

Looks good to me. Thank you!