Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
Rethrows checking is based on the interface type of the parameter, with
substitutions applied only when we need to figure out the thrown error
type. Fixes a regression caused by my attempt at dealing with parameter
packs in rethrows functions.
Effects checking for rethrowing functions was using unsubstituted
interface types for the parameter list. When a rethrows function has
parameter pack arguments, the interface type may have a different
number of parameters from the resulting argument list, causing the
effects checking to bail out early.
This has been wrong since the introduction of parameter packs, but
recent refactoring of effects checking ended up promoting this bug to
a compiler crash. Fix the bug, and make sure we don't crash if the
effects checker hits an issue here.
Fixes rdar://116740385.
In Swift 5.4, this worked:
func foo(_: (() throws -> ())? = nil) rethrows {}
foo() // no 'try' needed
However, this was an accident, because this was also accepted:
func foo(_: (() throws -> ())? = { throw ... }) rethrows {}
foo() // 'try' *should* be required here
This got fixed at some point recently, but since people rely on the
old case working for 'nil', let's add back a check for a 'nil'
default parameter.
Fixes rdar://problem/76169080.
The first test case added ideally shouldn't have any expected error or diagnostic.
However, due to SR-1534, there is an error emitted here. Thus, an expected error is
used here to show the compiler's behavior today.
If SR-1534 is fixed in the future, the first test case should no longer have any
expected error nor an expected note. However, the second test case should still be
left alone.
Addresses SR-14270
Original fix for SR-9102 stripped throws bit from the function types
nested inside optionals before attempting bindings, that doesn't
work with e.g. default parameter values because conversions from
throwing and non-throwing functions are only allowed in subtype
relationship but function types nested inside optionals are going
to be equated.
So this patch takes an alternative approach and attempts to pattern
match `nil` literal and `.none` use and classify argument as
non-contributing to throws.
Resolves: rdar://problem/47550715
We were assuming that variadic parameters are at the end, so we didn't
fill in all the types of the tuple elements in the tuple type we were
constructing.
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.
