@swift-ci create

Here is an example test case:

func f(_ k: () throws -> () = { }) rethrows {
  try k()
}
let x = f()

I think this should be added alongside related tests on diagnostics for rethrows.

It seems like this diagnostic is a stop-gap until we fix the problem.

Comment by Kenneth Chew (JIRA)

For clarification, there should not be any expected error and diagnostic here, correct? The error that shows up ("Call is to rethrows function, but a defaulted argument function can throw") should not appear? This seems to be what I gather from looking through SR-1534. Meanwhile something like

func x(_ f: () throws -> () = { throw SomeError.Badness }) rethrows {
  try f()
}
x()

should have the error and diagnostic?

For clarification, there should not be any expected error and diagnostic here, correct? The error that shows up ("Call is to rethrows function, but a defaulted argument function can throw") should not appear?

In an ideal world where SR-1534 is fixed, yes. However, I think that fixing SR-1534 is probably complicated and beyond the scope of a StarterBug. The task in this bug report is to add the test case along with the diagnostic to "pin down" the compiler's behavior today; in case someone else tries to understand when that diagnostic is emitted, they can take a look at the test case. If/When someone fixes SR-1534 in the future, they can change this test case from "error" to "works okay". So you can add two test cases like so:

// Should continue to emit an error after SR-1534 is fixed.
func f1(_ k: () throws -> () = { throw SomeError.Badness }) rethrows {
  // expected-error@-1{{ blah }}
  try k()
}
f1()

// Once SR-1534 is fixed, this code should compile instead of emitting an error.
func f2(_ k: () throws -> () = { }) rethrows {
  // expected-error@-1{{ blah }}
  try k()
}
f2()

Does that help?

Comment by Kenneth Chew (JIRA)

Yes, that's very helpful, thank you! I made a PR at #36455 - could you look at it when you get a chance, please?

Comment by Kenneth Chew (JIRA)

Added in #36455