* [Typechecker] resolveAttributedType() should invalidate the type repr after emitting a diagnostic, to prevent duplicate diagnostics later
* [Test] Update '@noescape' attribute diagnostics
* [Typechecker] Add a special diagnose method to TypeResolver that accepts a TypeRepr and invalidates it
* [Typechecker] Rename the special 'diagnose' method to 'diagnoseInvalid' for clarity
Detect difference in escapiness while matching function types
in the solver and record a fix that suggests to add @escaping
attribute where appropriate.
Also emit a tailored diagnostic when non-escaping parameter
type is used as a type of a generic parameter.
Some diagnostics got worse, but I think the reduction in compiler complexity
is worth it, and copy-and-pasting Swift 2 code is not likely to produce great
results anyway.
Also, this corrects an oversight where we did not reject @pseudogeneric on
function types in AST parsing.
For Swift 3 / 4:
Deprecate the spelling "ImplicitlyUnwrappedOptional", emitting a warning
and suggesting "!" in places where they are allowed according to
SE-0054.
In places where SE-0054 disallowed IUOs but we continued to accept them
in previous compilers, emit a warning suggesting "Optional" or "?" as
an alternative depending on context and treat the IUO as an Optional,
noting this in the diagnostic.
For Swift 5:
Treat "ImplicitlyUnwrappedOptional" as an error, suggesting
"!" in places where they are allowed by SE-0054.
In places where SE-0054 disallowed IUOs, emit an error suggestion
"Optional" or "?" as an alternative depending on context.
Per SE-0054, implicitly unwrapped optional is not a distinct type in the
type system, but rather just the notion that certain Optionals (denoted
by the sigil "!" rather than "?") can be implicitly unwrapped.
This is a first step in the direction of implementing this notion by
emitting a warning if the type is spelled out.
We cannot model a type variable bound to the ExtInfo of a function
type in the constraint solver, which means we have a hard time
propagating noescape-ness in some cases.
Fixes <rdar://problem/31910280> and <rdar://problem/32409133>.
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.
