New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-11574] Using try
instead of throws
should have a better diagnostic
#53979
Comments
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 let t : () try -> Int Does it make sense to have such diagnostic for this case as well? |
What about generalising it - instead of parsing a “try”, you can parse an identifier? |
@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— |
hi @theblixguy, yes, it could be generalized to trigger the diagnostic for any identifier, one only has to check if that identifier is a |
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`). |
Yeah, I didn't mean any identifier (sorry). I mean, if we have something like func foo() <whatever> {}
func foo() -> <whatever> {} and func foo() throwz {} // typo
func foo() -> throwz {} // typo which I think should also cause this diagnostic to be emitted. |
Typo correction for keywords might be a good idea, but that's beyond the scope of this specific issue. |
PR for this ticket merged : #27647 |
Looks good to me. Thank you! |
Additional Detail from JIRA
md5: 4b1deee143c591cfa05263856f246b0c
Issue Description:
Suppose you absentmindedly type
try
in a function declaration when you meant to typethrows
. Swift's diagnostic in this situation is not very good: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.
The text was updated successfully, but these errors were encountered: