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-8825] Metatype type joining not working in a member call on a IUO base #51333

Open
hamishknight opened this issue Sep 24, 2018 · 2 comments
Open

[SR-8825] Metatype type joining not working in a member call on a IUO base #51333

hamishknight opened this issue Sep 24, 2018 · 2 comments
Labels
access control Feature → modifiers: Access control and access levels bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself regression swift 4.2 type checker Area → compiler: Semantic analysis

Comments

@hamishknight
Copy link
Collaborator

Previous ID SR-8825
Radar rdar://problem/44728599
Original Reporter @hamishknight
Type Bug
Environment

Swift version 4.2-dev (LLVM c4295e5d5d, Clang afaa327551, Swift 2f557eb287)
Target: x86_64-apple-darwin17.7.0

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

md5: 141d5e262900e5aa3e7bc13cf6ed3f8f

Issue Description:

The following fails to compile in 4.2 (but it reportedly compiled in 4.1 – though I can't currently verify):

class C {}
class D : C {}
class E : C {}

struct X {
  func foo<T>(_: [T.Type]) where T : C {}
}

var x: X!
x.foo([D.self, E.self]) // error: Cannot convert value of type '[C.Type]' to expected argument type '[_.Type]'

Making x either a non-optional or a strong optional using either optional chaining or a force unwrap to perform the member access allows the code to compile.

In addition, doing the type join with instances rather than metatypes works:

struct X {
  func foo<T>(_: [T]) where T : C {}
}

var x: X!
x.foo([D(), E()]) // fine
@belkadan
Copy link
Contributor

It does indeed compile in 4.1.

@swift-ci create

@rudkx
Copy link
Member

rudkx commented Oct 10, 2018

I think we're failing here more or less out of bad luck at the moment, not inherently because an IUO is involved.

It looks like without the IUO we have:

  ($T2 involves_type_vars bindings={(subtypes of) C})
  ($T3 involves_type_vars bindings={(subtypes of) [$T2.Type]})

and decide to try bindings for $T2 first.

With the IUO (after deciding to force it), we have:

  ($T2 involves_type_vars bindings={(subtypes of) [$T4.Type]})
  ($T4 involves_type_vars bindings={(subtypes of) C})

and decide to try bindings for $T2 first (but this time it represents the array type), and then get stuck.

So we need to tweak the order in which bindings are attempting in order to fix this.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added regression swift 4.2 access control Feature → modifiers: Access control and access levels and removed 4.2 regression labels Nov 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
access control Feature → modifiers: Access control and access levels bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself regression swift 4.2 type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rudkx @belkadan @hamishknight @AnthonyLatsis