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-7144] Segmentation fault under swift::ValueDecl::getFormalAccessScope when using a capture list #49692

Closed
swift-ci opened this issue Mar 8, 2018 · 3 comments
Closed

[SR-7144] Segmentation fault under swift::ValueDecl::getFormalAccessScope when using a capture list #49692

swift-ci opened this issue Mar 8, 2018 · 3 comments
Assignees
@slavapestov
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software type checker Area → compiler: Semantic analysis

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Mar 8, 2018

Previous ID SR-7144
Radar rdar://problem/38394647
Original Reporter qnoid (JIRA User)
Type Bug
Status Resolved
Resolution Duplicate

Attachment: Download

Environment

Apple Swift version 4.0.3 (swiftlang-900.0.74.1 clang-900.0.39.2)
Target: x86_64-apple-macosx10.9

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, CompilerCrash, TypeChecker
Assignee @slavapestov
Priority Medium

md5: 394567996a43633da113fb78ff0dd2df

duplicates:

  • SR-5870 Crash when capture list references parameter of outer single-expression closure

Issue Description:

Test case

import Foundation

struct RecoverableProcess {
    
    typealias Recover  = (Process) -> Swift.Void
    
    let recover: Recover
    
    func perform(process: Process) {
        recover(process)
    }
}

func launch(process: Process, recover: RecoverableProcess? = nil) {
    
    process.terminationHandler = { process in
        //let canRecover = (recover != nil)
        DispatchQueue.main.async { [canRecover = (recover != nil), isSuccess = (process.terminationStatus == 0)] in
            
            guard isSuccess else {
                recover?.perform(process: process)
                return
            }
        }
    }
}

Steps:

swiftc main.swift

Actual:

Segmentation fault: 11

Expected:

Compile succesfully

Workaround:

Move the offending item in the capture list, outside.
@belkadan
Copy link
Contributor

belkadan commented Mar 8, 2018

With asserts:

Assertion failed: ((HadError || !M.is<SourceFile*>() || M.get<SourceFile*>()->ASTStage < SourceFile::TypeChecked) && "OverloadedDeclRef" "in wrong phase"), function walkToExprPre, file /Volumes/Data/swift-public/swift/include/swift/AST/ExprNodes.def, line 88.

1.  While walking into decl 'launch(process:recover:)' at <stdin>:14:1
2.  While walking into body of 'launch(process:recover:)' at <stdin>:14:1
3.  While walking into initializer for declaration 0x7f805f85ec70 at <stdin>:18:68

@swift-ci create

@slavapestov
Copy link
Member

Reduced:

let _: (Int) -> () = { process in
  _ = { [process] in }
}

This crashes in SILGen and not AST verifier but it's the same issue.

@slavapestov
Copy link
Member

The problem is that we type check capture lists before constraint solving, which is usually OK because they can only reference bindings in other statements and outer scopes. It's a problem in single-expression closures because we might not have assigned a type yet.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added the crash Bug: A crash, i.e., an abnormal termination of software label Dec 12, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@slavapestov slavapestov

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@slavapestov @belkadan @swift-ci @AnthonyLatsis