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

Jump to bottom

[SR-6876] Bad diagnostic with closures and overloaded method #49425

Closed
NachoSoto opened this issue Jan 30, 2018 · 7 comments
Closed

[SR-6876] Bad diagnostic with closures and overloaded method #49425

NachoSoto opened this issue Jan 30, 2018 · 7 comments
Assignees
@NachoSoto
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

@NachoSoto
Copy link
Contributor

Previous ID SR-6876
Radar rdar://problem/37044430
Original Reporter @NachoSoto
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Environment

  • Apple Swift version 4.0.3 (swiftlang-900.0.74.1 clang-900.0.39.2)

  • Apple Swift version 4.1 (swiftlang-902.0.34 clang-902.0.30)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, DiagnosticsQoI, TypeChecker
Assignee @NachoSoto
Priority Medium

md5: 39974f323899799e0c32d0d838184210

Issue Description:

Code:

class A {
    func f(_ a: Int) {}
    func f(_ b: String) {}
}

typealias Block = (A) -> Void

extension Int {
    static func with(_ a: (Int) -> Void) -> Int {
        return 0
    }
}

let blocks: [Block] = [
    {
        $0.f(
            Int.with {}
        ) 
    }
]

Produces:

error: 'f' produces '()', not the expected contextual result type 'Void'
                $0.f(
                   ^

Instead of the correct:

error: contextual type for closure argument list expects 1 argument, which cannot be implicitly ignored
                        Int.with {}
                                 ^
                                  _ in

Which it does if A.f doesn't have an overload.
@jckarter
Copy link
Member

@swift-ci create

@xedin
Copy link
Member

xedin commented Feb 1, 2018

@NachoSoto It doesn't look like error about contextual result should be produced by the latest beta and definitely not on master, it produces better error instead:

error: contextual type for closure argument list expects 1 argument, which cannot be implicitly ignored
               Int.with {}
                        ^
                         _ in

Can you please verify?

@NachoSoto
Copy link
Contributor Author

I tested this on the Swift 4.1 of Xcode 9.3 beta 1. Did you use the code with the f overload?

@xedin
Copy link
Member

xedin commented Feb 1, 2018

@NachoSoto We usually don't give any guarantees what is going to be in what beta, that said, I've tried the example from the description on master and one of the latest Xcode builds.

@NachoSoto
Copy link
Contributor Author

I can verify on the next Xcode beta then. Are there regression tests for this?

@mattneub
Copy link

This screen shows me getting "...produces Bool, not the expected contextual result type Bool", which is clearly nonsense.

![](Screen Shot 2019-01-21 at 5.13.04 PM.png)

The real problem seems to be that I'm not hitting any overload for my `canGoOn`, i.e. no overload of `canGoOn` takes what `$0` is.

@xedin
Copy link
Member

xedin commented Dec 10, 2019

If at all possible please verify using recent master snapshot. Code sample now produces correct diagnostic about missing closure argument.

@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
Assignees

@NachoSoto NachoSoto

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
Milestone
No milestone
Development

No branches or pull requests
4 participants
@xedin @jckarter @NachoSoto @mattneub