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.

Sign up for GitHub

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-13776] Undiagnosed generic argument mismatch for equatable requirement #56173

Closed
LucianoPAlmeida opened this issue Oct 25, 2020 · 5 comments · Fixed by #63222
Closed

[SR-13776] Undiagnosed generic argument mismatch for equatable requirement #56173

LucianoPAlmeida opened this issue Oct 25, 2020 · 5 comments · Fixed by #63222
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 generic constraints Feature → generics: generic constraints generics Feature: generic declarations and types type checker Area → compiler: Semantic analysis

Comments

@LucianoPAlmeida
Copy link
Collaborator

Previous ID SR-13776
Radar rdar://problem/70686873
Original Reporter @LucianoPAlmeida
Type Bug
Environment

Swift 5.3 XCode 12.2 Beta 3 (12B5035g)

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

md5: db9280c22e3407f5d282c9e01341fd33

Issue Description:

The problem here is that both collections elements are not constrained to be equal(C1.Element == C2.Element) so infer the `E` generic type of `f` from the arguments is ambiguous.

func f<E: Equatable>(_ e1: E, _ e2: E) {}

func f2<C1: Collection, C2: Collection>(_ c1: C1, _ c2: C2) where C1.Element: Equatable, C2.Element: Equatable {
  f(c1.map({ $0 }), c2.map({ $0 })) // type of expression is ambiguous without more context
}
@LucianoPAlmeida
Copy link
Collaborator Author

Reproduced on a near master

@LucianoPAlmeida
Copy link
Collaborator Author

cc @xedin

@LucianoPAlmeida
Copy link
Collaborator Author

A bit more simplified

struct A {}
struct B {}
func f<E: Equatable>(_ e1: E, _ e2: E) {}

f(A(), B()) // type of expression is ambiguous without more context

Edit: This seems like a slightly different problem because add the Equatable conformance to the types makes it produces the correct diagnostic.

@typesanitizer
Copy link

@swift-ci create

@LucianoPAlmeida
Copy link
Collaborator Author

I just hit this with another slightly different case, I think is the same problem but a bit different than both cases because it involves deep-equality and no generic arguments like C1 and C2 case.

// Similar signature of XCTest assert
public func XCTAssertEqual<T>(_ expression1: @autoclosure () throws -> T, _ expression2: @autoclosure () throws -> T) where T : Equatable {}

extension Collection {
  func aCollectionExtension() -> [SubSequence] { [] }
}

let expected : [[Int]] = []
let actual = [1, 2, 3].aCollectionExtension()

XCTAssertEqual(expected, actual) // type of expression is ambiguous without more context

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@LucianoPAlmeida LucianoPAlmeida mentioned this issue Jan 26, 2023
Merged
@AnthonyLatsis AnthonyLatsis added generics Feature: generic declarations and types generic constraints Feature → generics: generic constraints labels Jan 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
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 generic constraints Feature → generics: generic constraints generics Feature: generic declarations and types type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[ConstraintSystem] Handle ambiguities caused by requirement failures xedin/swift
3 participants
@typesanitizer @LucianoPAlmeida @AnthonyLatsis