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-5198] Diagnostics are pretty much always useless when errors involve type inference and closures #47774

Closed
NachoSoto opened this issue Jun 12, 2017 · 15 comments
Assignees
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-5198
Radar rdar://problem/33914448
Original Reporter @NachoSoto
Type Bug
Status Resolved
Resolution Done
Environment
  • Swift version 4.0 (swiftlang-900.0.43 clang-900.0.22.8)

  • Swift version 4.0 (swiftlang-900.0.63.10 clang-900.0.36)

  • Swift version 4.0.2 (swiftlang-900.0.69.1 clang-900.0.38)

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

  • 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: 6266990ac5135a6213094a3641402482

Issue Description:

I'm filing a particular example, but this is just one of the hundreds I've ran into regarding this since Swift 1.0. I honestly don't think this has gotten any better since the very first version.

This is a reduction from my own codebase. As I was going through the Swift 4.0 migrations, lots of places relying on tuple deconstruction in closure parameters stopped working, and diagnostics leave A LOT to be desired (https://twitter.com/NachoSoto/status/874336197568454656, https://twitter.com/NachoSoto/status/874336844757975040).

Consider this:

protocol P {
    associatedtype E    
}

struct S<A> {
    init() {}   
}

struct B<Y>: P {
    typealias E = Y
}

class X {
    func f1() -> S<Void> {
        return f(
            d: { _ in () }, 
            b: B(), 
            isRepeat: { _, _ in false }
        )
    }

    private func f<A, B: P>(
        d: @escaping (String) throws -> A, 
        b: B?, 
        isRepeat: @escaping (A, A) -> Bool
    ) -> S<A> where B.E == A {
        return S()
    }
}

This was compiling in Swift 3.x. Notice the `isRepeat` parameter I'm passing only has one _.

error: cannot convert value of type '()' to closure result type '_.E'
        d: { _ in () },

Say what? What's the problem in d? That looks correct to me...
Spoiler alert, the correct fix is changing isRepeat to

_, _

Instead of just _.

Again, like I said in the title, this is not an isolated bug, this happens ALL THE TIME when types can't be inferred. Diagnostic always point to the wrong thing with a useless message.

When are you going to start focusing on diagnostics? I have filed SO MANY diagnostic bugs that are still open:

@belkadan
Copy link
Contributor

cc @xedin

@NachoSoto
Copy link
Contributor Author

Another example showing how Swift fails to produce diagnostics in the most simple cases: SR-5233

@NachoSoto
Copy link
Contributor Author

Another really simple example @belkadan @xedin... SR-5243
I'm gonna keep filing these as I find them, hoping that one day getting things wrong will actually make Swift tell you exactly what's wrong.

@NachoSoto
Copy link
Contributor Author

And another one: https://bugs.swift.org/browse/SR-5245

@NachoSoto
Copy link
Contributor Author

FYI I've been updating the list of diagnostic issues here. It's grown to 14 including this one... I hope you guys can get to them soon cause the state of this in Swift 4.0 is currently pretty embarrassing.

@slavapestov
Copy link
Member

@swift-ci create

@NachoSoto
Copy link
Contributor Author

Any update on these? I just filed SR-6285, as I keep running into more and more useless diagnostics. Honestly, nobody cares about ABI stability if we can't actually write code.

@NachoSoto
Copy link
Contributor Author

And another one: SR-6292.

@NachoSoto
Copy link
Contributor Author

Is there going to be any focus on diagnostics for any future version of Swift or should I just give up filing these?

@xedin
Copy link
Member

xedin commented Jan 17, 2018

@NachoSoto Please keep filling the bugs! The problem is that, as I mentioned, the framework has to change completely before we can properly diagnose certain cases, I'm working on it, that just takes time to do.

@NachoSoto
Copy link
Contributor Author

Is this going to be a priority for Swift 5.0?

@NachoSoto
Copy link
Contributor Author

Added another one: SR-6876. Is this going to be a priority for Swift 5.0? I'm up to 17 unresolved diagnostic Jiras...

@xedin
Copy link
Member

xedin commented Jan 30, 2018

@NachoSoto Thanks! Diagnostics are always a priority, but fixing them usually requires significant time, that's why everything is going slowly.

@NachoSoto
Copy link
Contributor Author

Another one: SR-6994.

@xedin
Copy link
Member

xedin commented Feb 5, 2020

I have removed `, _` from `isRepeat` and tried with 5.2 snapshot and got following diagnostic:

error: contextual closure type '(Void, Void) -> Bool' expects 2 arguments, but 1 was used in closure body
            isRepeat: { _ in false }
                        ^
                         ,_

This is exactly what you are taking about so I'd really appreciate if you have verified using 5.2 nightly and closed. I'll take a look at the rest of the list meanwhile.

@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