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-910] Type Int1 does not conform to protocol BooleanType #43522

Closed
josephlord opened this issue Mar 10, 2016 · 20 comments
Closed

[SR-910] Type Int1 does not conform to protocol BooleanType #43522

josephlord opened this issue Mar 10, 2016 · 20 comments

Comments

@josephlord
Copy link

@josephlord josephlord commented Mar 10, 2016

Previous ID SR-910
Radar rdar://problem/33768959
Original Reporter @josephlord
Type Bug
Status Closed
Resolution Done

Attachment: Download

Environment

Xcode Version 7.3 beta (7D162j) - default toolchain

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, DiagnosticsQoI, TypeChecker
Assignee mkchoi212 (JIRA)
Priority Medium

md5: 0f2b3b38cf100f64f01b9de240c15935

Issue Description:

[NOTE - See comment below. The .whiteColor and .blackColor methods were not actually being called as they should have been. The error message is still very bad though so I'm not resolving the issue.]

Compile error "Type 'Int1' does not conform to protocol 'BooleanType'" is occurring when I don't think it should. First encountered in application code but the below example has the same error in the Playground.

This isn't quite the minimal sample where this is happening but it is getting close. The error does disappear at some point in simplification even when I don't think that the types should fundamentally change.

class PLStandardTableViewCell {
    var title: UILabel? = nil
    
    func setSelected(selected: Bool) {
        title?.textColor = selected ? .whiteColor : .blackColor
    }
}
@josephlord
Copy link
Author

@josephlord josephlord commented Mar 10, 2016

Actually the error seems to be caused by me forgetting that the whiteColor and blackColor are static methods not static variables of UIColor and should therefore be called with (). Even given that though the error message is awful.

@iby
Copy link

@iby iby commented Aug 14, 2016

I'm getting a similar thing with ternary operator and dictionaries, seeing it occasionally for the past 6 months.

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Aug 29, 2016

Comment by Paris Xavier Pinkney (JIRA)

I've just uploaded a sample playground that reproduces this bug SR-910.playground.zip

In the playground, I have two nested functions, compare1 and compare2 which are logically identical, however, the compiler displays bug within compare1 whilst compare2 executes the playground successfully.

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Oct 21, 2016

Comment by Zak Jacobson (JIRA)

pxpgraphics (JIRA User) there's a typo in your playground - I hope that's not the cause of your bug!

In: // return lhs < rhs ? .LessThan : .GreaterTham // <– failing operator `<`

.GreaterTham <– m/n

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Oct 21, 2016

Comment by Paris Xavier Pinkney (JIRA)

zoosnack (JIRA User) oh wow, my mistake. yes, that is the cause of my bug.

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Oct 21, 2016

Comment by Zak Jacobson (JIRA)

Awesome pxpgraphics (JIRA User)]! Glad to help.

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Aug 8, 2017

We no longer produce a diagnostic talking about Int1, but it's still not ideal: "Ambiguous reference to member '<'".

@xedin Want to take a look?

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Aug 8, 2017

@swift-ci create

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Aug 18, 2017

Comment by Mike Choi (JIRA)

@slavapestov Just to be clear on what should be happening, should the

"Ambiguous reference to member '<'"

message be something like

"error: pattern cannot match values of the type 'x'"

@xedin
Copy link
Member

@xedin xedin commented Aug 18, 2017

mkchoi212 (JIRA User) Here is the example in question:

enum E {
    case LessThan
    case EqualTo
    case GreaterThan
}

func compare(integer lhs: Int, with rhs: Int) -> E {
  guard lhs != rhs else { return .EqualTo }
  return lhs < rhs ? .LessThan : .GreaterTham
}

Currently on master is produces following diagnostic - "reference to member 'LessThan' cannot be resolved without a contextual type" but it actually should say that there is no such member GreaterTha*m* and it should be corrected to GreaterTha*n* with a fix-it.

@CodaFi
Copy link
Member

@CodaFi CodaFi commented Aug 18, 2017

@xedin In this case there's usually a leftover conversion constraint that we can use as a contextual type. Is it worth it to dig it out of the constraint system and type check the branches of the IfExpr with that as the target conversion type?

@xedin
Copy link
Member

@xedin xedin commented Aug 18, 2017

@CodaFi Yes, in this case it should be easy to do too because correct type is going to be contextual type of the constraint system.

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Aug 19, 2017

Comment by Mike Choi (JIRA)

@xedin Just fixed the bug. I decided to place the test under test/Constraints/diagnostics.swift with the same .GreaterTham example. Is this ok?

@xedin
Copy link
Member

@xedin xedin commented Aug 19, 2017

mkchoi212 (JIRA User) Yes, that's fine!

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Aug 20, 2017

Comment by Mike Choi (JIRA)

I've submitted a pull request for this issue: #11531

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Aug 22, 2017

mkchoi212 (JIRA User) Can you screen SR-2623 and see if its the same issue?

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Aug 22, 2017

Sorry, I meant SR-2326.

@xedin
Copy link
Member

@xedin xedin commented Aug 22, 2017

mkchoi212 (JIRA User) It's similar yes, it should says that type-checking of ".foo" and ".bar" requires contextual type which wasn't provided instead of talking about "==" ambiguity.

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Aug 30, 2017

Comment by Mike Choi (JIRA)

PR merged

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Aug 31, 2017

Thank you, mkchoi212 (JIRA User)!

@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
Projects
None yet
Development

No branches or pull requests

6 participants