Previously we had more ad hoc logic that tried to decide if it was
worth desugaring a type based on its structure. Now we instead look
for a typealias that might actually benefit from desugaring, and if
we don't find one we won't show the 'aka' note.
The recent @escaping on variadic argument closures back-compat fix is
the first Swift 3.0 compatibility behavior that we don't want to carry
forwards indefinitely into the future. To address this, we
version-gate the diagnostic suppression.
Makes it an official compatibility check. Creates new test directory
for compatibility testing. Allow -swift-version 4 so that we can test
it both ways.
Var-arg closures are already escaping, so we typically want to issue
an error if @escaping is specified. To not do sure will confuse and
give a false impression on the un-annotated semantics and whether it
is needed. But, 3.0 shipped with a bug where we didn't consistently
apply the no-escape-by-default rule here, and thus it was semantically
meaningful (and needed).
In order to preserve source compatibility, albeit at the expense of
developers on versions 3.0.1 and later in the Swift 3 family, we
suppress the error if we see @escaping. Either way, this is a
relatively uncommon usage, so the confusion won't be too wide spread.
We have a special case check for the no-escape-by-default rules for a
computed property setter's newValue argument, which if a closure,
obviously has to be escaping. But, we checked this by checking the
type's overall DeclContext, which unfortunately meant we also made
nested closures escaping implicitly. This fixes that to only tack on
the implicit escaping at the top level for the setter's type.
A variadic parameter of function type must be @escaping -- we cannot
reason about an array of non-escaping closures, so this was a safety
hole.
Also, attempting to define an @autoclosure variadic did not produce a
diagnostic, but would fail later on if you actually tried to do
anything with it. Let's ban this completely.
Both changes are source breaking, but impact is limited to code that
was already only marginally valid.
Prior, binding generic args in dictionary type checking would double
resolve the key and value types a second time, emitting duplicated
errors potentially. Instead, we reuse the resolved types.
Adds in helpful notes when a closure type argument is already
escaping, and thus doesn't need annotation. The common case targeted
now is Optional and IUO, which is the biggest bang for our buck
without needlessly complicating the type options.
Test cases included for the new note, and potential interactions.
In the future we'd like some kind of parent pointer, or context stack
to give better diagnostics universally. For now, we hack it by having
ImmediateOptionalTypeArgument as a special flag.
In situations where @escaping is used in non-function-parameter
positions, we give an incorrect diagnostic message pertaining to
function types. Instead, we should just state that this is not allowed
in non-function-parameter positions.
This includes the general message fix. Unfortunately, this does not
include more friendly messages for special cases, e.g. closure members
of aggregate and optional closures. That may be possible with more
nested type context information in TypeCheckType.
...not just those where the functions match otherwise. This allows the
fix-it to be provided in cases where the closure being passed is a
subtype, or when there are generics involved. Yes, the '@escaping'
might not be the only issue, but it will need to get fixed, and
probably independently of anything else that's going on (except
perhaps calling the wrong function).
rdar://problem/27729540
Extends the more useful diagnostics for non-escaping function
parameters used in @escaping contexts to apply to all functions that
are equivalent modulo ExtInfo.
Issue better diagnostics, along with notes and fixits, for the common
case of using an implicitly non-escaping parameter of function type in
a context expecting an @escaping closure. Provides even more specific
diagnostics for common scenarios such as passing to another function
or assignment.
