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

[josephlord]

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]

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]

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

[swift-ci]

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]

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]

Comment by Paris Xavier Pinkney (JIRA)

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

[swift-ci]

Comment by Zak Jacobson (JIRA)

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

[slavapestov]

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]

@swift-ci create

[swift-ci]

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]

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]

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

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

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]

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

[swift-ci]

Comment by Mike Choi (JIRA)

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

[slavapestov]

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

[slavapestov]

Sorry, I meant SR-2326.

[xedin]

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]

Comment by Mike Choi (JIRA)

PR merged

[slavapestov]

Thank you, mkchoi212 (JIRA User)!