When calling a throwing function without 'try', let's suggest multiple
possibilities of note + fix-it for user to choose from.
Resolves: rdar://problem/33040113
My original fix for rdar://problem/31794932 didn't work for generic
functions because it was checking in the unsubstituted interface
type. Check structurally instead. Fixes rdar://problem/31794932.
The throw-checking code wasn't properly coping with functions that
take a single, labeled argument, due to the longstanding lie that
pretends that functions take a tuple argument vs. zero or more
separate arguments. Here, the lie manifests as spurious "call can
throw, but is not marked as such" errors.
Fixes rdar://problem/31794932.
A catch block can only be entered if the do block threw an error. In a
rethrows function, if the do block throws an error only under rethrows
conditions, then the catch block can only be entered under rethrows
conditions, which means the catch block can unconditionally throw and
it's still safe.
This enables code that looks like
```swift
func foo(f: () throws -> Void) rethrows {
do {
try f()
} catch is SomeError {
throw OtherError()
}
}
```
This is a case where we used to produce:
<unknown>:0: warning: no calls to throwing functions occur within 'try' expression
Which is bogus, due to the try expr implicitly generated as part of the
implicit super.init call for an init that doesn't otherwise contain a super.init.
Silence this warning by ignoring implicitly generated trys, since this try gets
produced before name binding has resolved exactly which try is being invoked.
