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-680] rethrows analysis breaks when wrapped in another rethrows function #43295

Open
lilyball mannequin opened this issue Feb 5, 2016 · 2 comments
Open

[SR-680] rethrows analysis breaks when wrapped in another rethrows function #43295

lilyball mannequin opened this issue Feb 5, 2016 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@lilyball
Copy link
Mannequin

lilyball mannequin commented Feb 5, 2016

Previous ID SR-680
Radar rdar://problem/27868617
Original Reporter @lilyball
Type Bug
Status Reopened
Resolution
Environment

Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81)
Target: x86_64-apple-darwin15.3.0

Apple Swift version 2.2 (swiftlang-703.0.6 clang-703.0.16)
Target: x86_64-apple-macosx10.9

Additional Detail from JIRA
Votes 1
Component/s Compiler
Labels Bug
Assignee None
Priority

md5: 45c8f78cc7660e33aa88968b85b08224

is blocked by:

Issue Description:

rethrows functions can't throw unless their closure throws. By extension, this means that a rethrows function cannot call another throws function. But it seems that if the call to the other throws function is itself wrapped in a closure passed to another rethrows function, the compiler gets confused and allows it. I first hit this when using SequenceType.flatMap, but the following snippet reproduces it:

struct MyErr: ErrorType {}

func foo<T>(@noescape f: () throws -> T) throws -> T {
    throw MyErr()
}

func bar<T,U>(x: T, @noescape f: T throws -> U) rethrows -> U {
    // if we called
    //   return try foo({ try f(x) })
    // the compiler would yell at us for calling a `throws` function.
    // But if we wrap it in `idemp()` the compiler doesn't yell at us
    // even though it should.
    return try idemp(x, f: { x in try foo({ try f(x) }) })
}

func idemp<T,U>(x: T, @noescape f: T throws -> U) rethrows -> U {
    return try f(x)
}

// As a consequence, because foo() unconditionally throws, the following
// results in the program aborting execution (without even an error message).
print(bar(1, f: { $0+1 }))
@swift-ci
Copy link
Collaborator

Comment by Ilya Puchka (JIRA)

I'm able to reproduce the same (looks like) issue with this snippet both in Xcode 7 and Xcode 8 beta 5 (Apple Swift version 3.0 (swiftlang-800.0.41.2 clang-800.0.36) Target: x86_64-apple-macosx10.9)

enum SomeError: Error {
    case error
}
var error: Error? = nil

func smthThatThrows() throws -> Void {
    if let error = error { throw error }
}
func smthThatRethrows(block: () throws -> Void) rethrows -> Void {
    try smthElseThatRethrows {
        try smthThatThrows()
    }
}

func smthElseThatRethrows(block: () throws -> Void) rethrows -> Void {
    return try block()
}

do {
    try smthThatRethrows() {}
}
catch { print(error) }

error = SomeError.error

do {
    try smthThatRethrows() {} //causes runtime crash
}
catch { print(error) }

Crash goes away if smthThatRethrows is marked with throws instead of rethrows
The other way to fix it is to explicitly specify closure type as throwing:

let block: () throws -> Void = {}
do {
    try smthThatRethrows(block: block) //does not crash, prints error
}
catch { print(error) }

@slavapestov
Copy link
Member

Reduced test case:

enum MyError : Error {
  case bad
}
func foo(_: () throws -> ()) rethrows {}
func bar(_ fn: () throws -> ()) rethrows {
  try foo { throw MyError.bad }
}

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
Projects
None yet
Development

No branches or pull requests

2 participants