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-4372] Captured let variable assigned wrong calling convention #46951

Open
beccadax opened this issue Mar 27, 2017 · 0 comments
Open

[SR-4372] Captured let variable assigned wrong calling convention #46951

beccadax opened this issue Mar 27, 2017 · 0 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself SILGen Area → compiler: The SIL generation stage

Comments

@beccadax
Copy link
Contributor

Previous ID SR-4372
Radar None
Original Reporter @beccadax
Type Bug

Attachment: Download

Environment

Swift 4 at commit bf1791b (based on master commit 70f3d93), macOS 10.12.3 (16D32), Xcode 8.3 beta 4 (8W143q)

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

md5: 1ddb2f0a67bdb030ed22f416d3bdef3c

Issue Description:

When compiling this file:

// Does not have to be a function; I first saw this with String(reflecting:).
func take(_: CustomStringConvertible) {}

// Must be in a function.
func wat() {
  // Must be an existential; Any works too.
  let value: CustomStringConvertible
  
  // Must be initialized on a separate line.
  value = "x"   
  
  // Must be in a closure and must be immediately called.
  ({ take(value) })()
}

Swift 4, with PR #8366 applied to avoid a crash, complains:

capturetest.swift:13:4: error: immutable value 'value' may not be passed inout
  ({ take(value) })()
   ^

This is at least better than Swift 3.1, which goes into an infinite loop. (That's with the parentheses around the closure; without them, it mis-parses the expression entirely.)

Examining the SIL, it looks like something decides that `value` needs to be passed to `take(_🙂` as `@lvalue_aliasable`, and the DI lifetime checker accurately complains that you can't do that to a `let` variable.

@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 SILGen Area → compiler: The SIL generation stage
Projects
None yet
Development

No branches or pull requests

1 participant