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-7171] failure to type check expression involving inout closure #49719

Open
rudkx opened this issue Mar 10, 2018 · 2 comments
Open

[SR-7171] failure to type check expression involving inout closure #49719

rudkx opened this issue Mar 10, 2018 · 2 comments
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 type checker Area → compiler: Semantic analysis

Comments

@rudkx
Copy link
Member

rudkx commented Mar 10, 2018

Previous ID SR-7171
Radar None
Original Reporter @rudkx
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, DiagnosticsQoI, TypeChecker
Assignee None
Priority Medium

md5: adf825b6be9863b3d0e25514f78c8877

Issue Description:

It seems like we should be able to type check this without issue, but fail to and then eventually hit a verification failure while trying to diagnose.

not an l-value
UNREACHABLE executed at /Users/mark_lacey/swift-project/swift/include/swift/AST/ExprNodes.def:98!

It seems that the issue is that we fail to match up inout to inout for the closure because we expect to only ever match up lvalues to inout.

precedencegroup WithPrecedence {
  associativity: left
  higherThan: BitwiseShiftPrecedence
}

infix operator ... : WithPrecedence

func ... <T>(lhs: inout T, rhs: (inout T) -> T) -> T {
  return rhs(&lhs)
}

struct S {
  var i: Int
}

var s = S(i: 7)

&s...{ $0.i = 1 }
@rudkx
Copy link
Member Author

rudkx commented Mar 12, 2018

Another variation on this.

This time defining an overload that takes an optional results in the verification failure.

precedencegroup WithPrecedence {
  associativity: left
  higherThan: BitwiseShiftPrecedence
}

infix operator .* : WithPrecedence
infix operator .*. : WithPrecedence

func .* <T>(lhs: T, rhs: (inout T) -> ()) -> T {
  var l = lhs
  rhs(&l)
  return l
}

func .* <T>(lhs: T?, rhs: (inout T) -> ()) -> T? {
  guard let lhs = lhs else { return nil }
  var l = lhs
  rhs(&l)
  return l
}

struct S {
  var i: Int
  var j: Float
}

let s = S(i: 7, j: 0)
let o: S? = S(i: 3, j: 4)
let t = s.*{ $0.i = 1 }.*{ $0.j = 2 }
let u = o.*{ $0.i = 1 }.*{ $0.j = 2 }
let v: S? = nil
let w = v.*{ $0.i = 1 }.*{ $0.j = 2 }

print(s.i)
print(s.j)

print(t.i)
print(t.j)

print(u.i)
print(u.j)

print(v.i)
print(v.j)

@belkadan
Copy link
Contributor

No longer crashes, but the diagnostic is pretty lousy:

<stdin>:18:13: error: cannot convert value of type '()' to closure result type '_'
&s...{ $0.i = 1 }
       ~~~~~^~~

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
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 type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

2 participants