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-5199] Yet another useless diagnostic for tuple destructuring #47775

Closed
NachoSoto opened this issue Jun 12, 2017 · 6 comments
Closed

[SR-5199] Yet another useless diagnostic for tuple destructuring #47775

NachoSoto opened this issue Jun 12, 2017 · 6 comments
Assignees
@xedin
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-5199
Radar None
Original Reporter @NachoSoto
Type Bug
Status Resolved
Resolution Done
Environment

Swift version 4.0 (swiftlang-900.0.43 clang-900.0.22.8)

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

md5: 2834b1398a14298c3c95e5df6e477bc5

Issue Description:

struct T {}

extension Sequence where Iterator.Element == (key: String, value: String?) {
    func f() -> [T] {
        return self.map { (key, value) in
            T()
        }
    }
}
error: repl.swift:5:21: error: 'map' produces '[T]', not the expected contextual result type '[T]'
        return self.map { (key, value) in
                    ^

See SR-5198 for another example and https://twitter.com/NachoSoto/status/874336844757975040 for discussion on Twitter.
@belkadan
Copy link
Contributor

Thank you for filing all these, Nacho!

@xedin: why aren't we getting the tuple destructuring diagnostic here?

@NachoSoto
Copy link
Contributor Author

@belkadan I'm 99% sure this isn't isolated to tuple destructuring (that's just how I've ran into all these easy to spot cases). Like I said in SR-5198 anything that involves closures that fail to type check pretty much never offers useful diagnostics.

@belkadan
Copy link
Contributor

Yeah, that's fair. There must be somewhere assuming that if something doesn't type-check it's the return type's fault. (I don't work on the expression type checker very much so I'm not a good source of information there.)

@xedin
Copy link
Member

xedin commented Jun 14, 2017

@belkadan It's because of the way we are trying to re-typecheck function type of the expression in `visitApplyExpr` of `FailureDiagnosis`, I'm actively working on improving all diagnostics related to closures like that...

@xedin
Copy link
Member

xedin commented Jun 21, 2017

Since portion of the SE-0110 has been reverted, this example type-check correctly again, I've added it as port of the #10099 to regression tests as well.

@xedin
Copy link
Member

xedin commented Jun 21, 2017

#10099 also makes it correctly diagnose as tuple destructuring if we ever to bring that back...

@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

@xedin xedin

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
3 participants
@xedin @NachoSoto @belkadan