Skip to content
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

Closed
beccadax opened this issue Oct 6, 2019 · 9 comments
Closed
Assignees
Labels
compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation good first issue Good for newcomers improvement parser Area → compiler: The legacy C++ parser

Comments

@beccadax
Copy link
Contributor

beccadax commented Oct 6, 2019

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
Copy link
Contributor

vguerra commented Oct 8, 2019

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
Copy link
Collaborator

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

@beccadax
Copy link
Contributor Author

beccadax commented Oct 9, 2019

@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
Copy link
Contributor

vguerra commented Oct 9, 2019

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
Copy link
Contributor

vguerra commented Oct 9, 2019

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
Copy link
Collaborator

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
Copy link
Mannequin

rintaro mannequin commented Oct 17, 2019

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
Copy link
Contributor

vguerra commented Oct 17, 2019

PR for this ticket merged : #27647

@beccadax
Copy link
Contributor Author

Looks good to me. Thank you!

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation good first issue Good for newcomers improvement parser Area → compiler: The legacy C++ parser
Projects
None yet
Development

No branches or pull requests

3 participants