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-11934] Segfault in TypeChecker::conformsToProtocol when using @autoclosure Any... #54353

Closed
swift-ci opened this issue Dec 9, 2019 · 10 comments
Assignees
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 Dec 9, 2019

Previous ID SR-11934
Radar rdar://problem/57824033
Original Reporter dhoerl (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

Apple Swift version 5.1.2 (swiftlang-1100.0.278 clang-1100.0.33.9)
Target: x86_64-apple-darwin19.0.0

Save the above code in a file, then run it with "swift crash.swift"

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

md5: 6c5e153499d805f69d07a931d862ac5b

Issue Description:

func LOG(_ flag: Int, _ items: @autoclosure Any..., separator: String = " ", terminator: String = "\n") {
    do {
        // Commenting these out has no effect
        let str = items.map{String(describing: $0)}.joined(separator: separator)
        print(str, terminator: terminator)
    }
}
func expensiveFunc() -> String {
    print("CALLED")
    return "EXPENSIVE!!!"
}
LOG(1, "Does it get called?", 5, 7, expensiveFunc())        // Segmentation fault
LOG(0, "Does it get called?", expensiveFunc())            // OK
@typesanitizer
Copy link

Minimal reproducer

func f(_ xs: @autoclosure Any...) { return }
f(0)

Top of the stack trace when the crash happens:

4  swift                    0x000000010f48e96f swift::TypeChecker::conformsToProtocol(swift::Type, swift::ProtocolDecl*
, swift::DeclContext*, swift::OptionSet<swift::ConformanceCheckFlags, unsigned int>, swift::SourceLoc) + 95            
5  swift                    0x000000010f27dd27 swift::constraints::ConstraintSystem::getPotentialBindings(swift::TypeVa
riableType*) + 11703                           

@swift-ci create

@typesanitizer
Copy link

As a work-around, you could use an array [@autoclosure Any] to get the same effect, except that you have some extra square brackets. That seems to not crash the compiler.

@beccadax
Copy link
Contributor

@swift-ci create

@swift-ci
Copy link
Collaborator Author

Comment by David Hoerl (JIRA)

theindigamer (JIRA User) Thanks for the workaround. I was playing with this as a future extension to something I use regularly (the code minus the autoclosure). I didn't think to reduce the error to the absolute minimum as you did - will work harder on future posts.

@theblixguy
Copy link
Collaborator

I am surprised an [@autoclosure <type_name>] works - I thought we needed a function type as an argument to @ autoclosure? Variadic autoclosures were already banned long time ago, so this looks like a regression. I'll take a look!

@theblixguy
Copy link
Collaborator

Here's a fix for the original problem: #28677

I've also found a different crash:

func foo(_ closure: @autoclosure () -> String...) // gets diagnosed
foo("A") // but crashes here (although it shouldn't)

I'll file a separate bug for this.

The [@autoclosure T] case should also be an error as T is not a function type, but I can create a separate bug for this as well.

@hamishknight
Copy link
Collaborator

@theblixguy I just filed a bug for [@autoclosure T], looks like we just allow it in any non-parameter position if it's used with a non-function type

@theblixguy
Copy link
Collaborator

@hamishknight Thank you! I'll investigate that further, that seems to me like a more general problem with validating @autoclosure.

@theblixguy
Copy link
Collaborator

Fixed on master - please verify using the next available development snapshot!

@xedin
Copy link
Member

xedin commented Dec 18, 2019

Resolved by #28819 dhoerl (JIRA User) Please use next available nightly snapshot of master to verify.

@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
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
Development

No branches or pull requests

7 participants