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-10852] [Opaque Result Types] Generic parameter 'τ_0_0' could not be inferred #53242

Closed
theblixguy opened this issue Jun 7, 2019 · 10 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 opaque types Feature → types: opaque types operators Feature: operators swift 5.1 type checker Area → compiler: Semantic analysis

Comments

@theblixguy
Copy link
Collaborator

Previous ID SR-10852
Radar rdar://problem/51526846
Original Reporter @theblixguy
Type Bug
Status Resolved
Resolution Done
Environment

Xcode 11 Beta 1, Swift 5.1, macOS 10.15 Developer Beta 1 (19A471t)

Additional Detail from JIRA
Votes 1
Component/s Compiler
Labels Bug, DiagnosticsQoI, OpaqueResultTypes
Assignee @theblixguy
Priority Medium

md5: f781c969fc89c0f73616e7ae7b35dbfa

Issue Description:

I don't think "τ_{depth}_{index}" is supposed to leak into diagnostics:

protocol EquatableBox {
  associatedtype Value: Equatable
  var value: Value { get }
}

func ==<T: EquatableBox, U: EquatableBox>(lhs: T, rhs: U) -> Bool where T.Value == Int, U.Value == Int {
  return lhs.value == rhs.value
}

struct ConcreteEquatableBox: EquatableBox {
  typealias Value = Int
  let value: Value
}

func someEquatableBox() -> some EquatableBox {
  return ConcreteEquatableBox(value: 5)
}

let a = someEquatableBox()
let b = someEquatableBox()

let _ = a == b // Generic parameter 'τ_0_0' could not be inferred
@theblixguy
Copy link
Collaborator Author

cc @jckarter

@jckarter
Copy link
Member

jckarter commented Jun 7, 2019

I wonder if it's getting confused doing overload resolution on `==` and misattributing the type error.

@swift-ci
Copy link
Collaborator

swift-ci commented Jun 8, 2019

Comment by Tapan Thaker (JIRA)

Taking this bug.
Just got a diagnostics PR landed in the TrySwift conf, so this would be a nice place to contribute next.

@swift-ci
Copy link
Collaborator

Comment by Tapan Thaker (JIRA)

The compilation will pass if I change the above `==` overload to below.

func ==<T: EquatableBox, U: EquatableBox>(lhs: T, rhs: U) -> Bool  {
  return lhs.value == rhs.value
}

My thought process is that, constraint solver is somehow not attributing the correct `==` overload with the where constraint.

@swift-ci
Copy link
Collaborator

Comment by Tapan Thaker (JIRA)

@jckarter: To me, it looks like ConstraintSolver solved and inferred the correct types. Also, I get that the compiler could not find a
== overloading for some EquatableBox. Just not sure what diagnostic should now be emitted to make the problem obvious.

---Solution---
Fixed score: 2 0 0 0 0 0 0 0 0 0 0 0
Type variables:
  $T66 as some EquatableBox @ locator@0x7fa5430a3078 [OverloadedDeclRef@Hello.swift:26:11 -> generic parameter 'U']
  $T2 as some EquatableBox @ locator@0x7fa54389d7a0 [DeclRef@Hello.swift:26:14]
  $T1 as some EquatableBox @ locator@0x7fa54389d718 [DeclRef@Hello.swift:26:9]
  $T3 as Bool @ locator@0x7fa54389d830 [Binary@Hello.swift:26:11 -> function result]
  $T0 as (some EquatableBox, some EquatableBox) -> Bool @ locator@0x7fa54389a600 [OverloadedDeclRef@Hello.swift:26:11]
  $T65 as some EquatableBox @ locator@0x7fa5430a3030 [OverloadedDeclRef@Hello.swift:26:11 -> generic parameter 'T']

Overload choices:
  locator@0x7fa54389d7a0 [DeclRef@Hello.swift:26:14] with Hello.(file).b@Hello.swift:24:5 as b: some EquatableBox

  locator@0x7fa54389d718 [DeclRef@Hello.swift:26:9] with Hello.(file).a@Hello.swift:23:5 as a: some EquatableBox

  locator@0x7fa54389a600 [OverloadedDeclRef@Hello.swift:26:11] with Hello.(file).==@Hello.swift:6:6 as ==: ($T65, $T66) -> Bool


Constraint restrictions:

Disjunction choices:

Opened types:
  locator@0x7fa54389a600 [OverloadedDeclRef@Hello.swift:26:11] opens τ_0_0 -> $T65, τ_0_1 -> $T66

Fixes:
  [fix: skip same-type generic requirement] @ locator@0x7fa5430a3228 [OverloadedDeclRef@Hello.swift:26:11 -> opened generic -> type parameter requirement #&#8203;2 (same-type)]
  [fix: skip same-type generic requirement] @ locator@0x7fa5430a32d8 [OverloadedDeclRef@Hello.swift:26:11 -> opened generic -> type parameter requirement #&#8203;3 (same-type)]
---Constraint solving for the expression at [Hello.swift:26:9 - line:26:9]---
  (overload set choice binding $T0 := some EquatableBox)
---Initial constraints for the given expression---
(declref_expr type='some EquatableBox' location=Hello.swift:26:9 range=[Hello.swift:26:9 - line:26:9] decl=Hello.(file).a@Hello.swift:23:5 function_ref=unapplied)
Score: 0 0 0 0 0 0 0 0 0 0 0 0
Type Variables:
  $T0 [lvalue allowed] [noescape allowed] as some EquatableBox @ locator@0x7fa542960600 [DeclRef@Hello.swift:26:9]

Active Constraints:

Inactive Constraints:
Resolved overloads:
  selected overload set choice a: $T0 == some EquatableBox

  (found solution 0 0 0 0 0 0 0 0 0 0 0 0)
---Solver statistics---
Total number of scopes explored: 1
Maximum depth reached while exploring solutions: 1
Time: 1.239170e+02ms

@jckarter
Copy link
Member

Thanks for looking into this! @xedin where would be a good place to improve the diagnostic here? The issue is that the constraints on
`where T.Value == Int, U.Value == Int` cannot be satisfied by `some EquatableBox` since the opaque type doesn't reveal the associated type of the underlying type. It seems like this would be a nice thing to provide diagnostics for in the general case of a generic parameter type that's missing constraints to be the generic argument to another call.

@xedin
Copy link
Member

xedin commented Jun 15, 2019

tt (JIRA User) Looks like we already record fixes for unsatisfied requirements and form a solution so the only remaining problem to figure out is why don't we emit the diagnostics for recorded fixes.

Fixes:
  [fix: skip same-type generic requirement] @ locator@0x7fa5430a3228 [OverloadedDeclRef@Hello.swift:26:11 -> opened generic -> type parameter requirement #&#8203;2 (same-type)]
  [fix: skip same-type generic requirement] @ locator@0x7fa5430a32d8 [OverloadedDeclRef@Hello.swift:26:11 -> opened generic -> type parameter requirement #&#8203;3 (same-type)]

@xedin
Copy link
Member

xedin commented May 8, 2020

Looks like we produce a much better error now on master:

error: operator function '==' requires the types '(some EquatableBox).Value' and 'Int' be equivalent
let _ = a == b
          ^

note: where 'T.Value' = '(some EquatableBox).Value'
func ==<T: EquatableBox, U: EquatableBox>(lhs: T, rhs: U) -> Bool where T.Value == Int, U.Value == Int {
     ^

WDYT, @theblixguy?

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@Chevel
Copy link

Chevel commented Jan 19, 2023

Follow up on this.
I am able to reproduce it with a much simpler example. Maybe it will offer some insight.

import SwiftUI
enum Fruit {

    case apple
    case orange

    var icon: (some View)? {
        switch self {
        case .apple: return Image(systemName: "applelogo")
        case .orange: return nil
        }
    }

}

@AnthonyLatsis AnthonyLatsis added type checker Area → compiler: Semantic analysis operators Feature: operators swift 5.1 labels Jan 20, 2023
@AnthonyLatsis
Copy link
Collaborator

AnthonyLatsis commented Jan 20, 2023

I am able to reproduce it with a much simpler example.

@Chevel Yours appears to be a different bug, please open a new issue. This particular one was fixed.

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 opaque types Feature → types: opaque types operators Feature: operators swift 5.1 type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

6 participants