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-13483] Poor closure diagnostics #55926

Closed
theblixguy opened this issue Sep 1, 2020 · 7 comments
Closed

[SR-13483] Poor closure diagnostics #55926

theblixguy opened this issue Sep 1, 2020 · 7 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation type checker Area → compiler: Semantic analysis

Comments

@theblixguy
Copy link
Collaborator

Previous ID SR-13483
Radar rdar://problem/68296103
Original Reporter @theblixguy
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, DiagnosticsQoI, TypeChecker
Assignee None
Priority Medium

md5: 3ec8963d9061069a42e3d0cd5e2d570e

Issue Description:

If I have the following code

(0..<10).map { x 
  x + 1
}

I get:

contextual type for closure argument list expects 1 argument, which cannot be implicitly ignored

but the problem is the missing in after x.

Similarly, if I have the following code:

(0..<10).map { x, y in }

I get the same error as above, but the problem is that I have provided two arguments but closure expects 1.

@typesanitizer
Copy link

@swift-ci create

@xedin
Copy link
Member

xedin commented Sep 4, 2020

The problem here is that `x` is treated as just a regular reference since syntax for the closures is ambiguous in this case that's why we produce a diagnostic which says that there is a parameter missing - no way to figure out what user meant here...

@theblixguy
Copy link
Collaborator Author

Hmm, that's unfortunate. I was hoping this could be resolved in the parser perhaps (by parsing x as a parameter and diagnosing the missing in maybe). What do you think about the second case? We have valid syntax but the problem is a mismatch between the number of parameters provided and what the closure expects (2 vs 1).

@xedin
Copy link
Member

xedin commented Sep 4, 2020

The second one looks like a bug to me, it should have a fix to remove a second argument...

@xedin
Copy link
Member

xedin commented Mar 29, 2021

luciano (JIRA User) Looks like compiler now correctly detects that there is only one argument expected by `map` but it still produces wrong fix-it to add `_ in`. Would you like to look into fixing this?

@LucianoPAlmeida
Copy link
Collaborator

Yeah, there is already a fix for that right? So this would be just to attempt and record in that situation
Adding to queue, thanks @xedin

@LucianoPAlmeida
Copy link
Collaborator

Fixed on main by https://github.com/apple/swift/pull/36883

@theblixguy can you please verify on the next available snapshot =]

@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
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

4 participants