Until the point where ASTScope-based unqualified name lookup is the
default, unqualified name lookup can still find names declared *after*
the source location. The 'hasType' check no longer makes sense, so actually
check the source location of the entity we found.
When using the ASTScope-based unqualified name lookup, we might find
things that are in scope but haven't been fully type-checked yet;
allow us to perform type checking.
While the use of a local property from within its own accessors is a
bit dubious, Swift 3 only warned on it, so model the existing lookup
behavior in the scope map.
ExprCollector is extended to cover all generic collections instead of
only dictionary expressions. Contextual type propagation is extended
to support partial solving of collections embedded into coerce expressions.
This reverts commit f590a1ba03.
It breaks this kind of code:
test.swift:2:34: error: cannot convert value of type 'Int' to expected element type 'UInt32'
let lengthBytes: [UInt32] = [55 * 8, 0]
~~~^~~
UInt32( )
The type checker had some logic for performing specific checking for
explicit bridging casts of generic types based on knowledge of
Array/Dictionary/Set, but pretended no other bridged generic types
existed. That's incorrect now; simply require them to match exactly.
Fixes rdar://problem/27539951.
ExprCollector is extended to cover all generic collections instead of
only dictionary expressions. Contextual type propagation is extended
to support partial solving of collections embedded into coerce expressions.
This helps when manually migrating Swift 2 code to Swift 3, which
includes SE-0116 (id-as-Any). We already did this for specific bridged
types (like URL and NSURL); this just adds a special case for
Any/AnyObject.
rdar://problem/27865590
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.
SILType substitutions are still done with the old form, and until
BoundGenericTypes hold conformances, we still have to pass around
a ModuleDecl in a few places we really shouldn't, but one step
at a time.
Lazy property initializers can refer to 'self' either directly or
implicitly (via references to instance members). Model this in
ASTScope-based unqualified name lookup.
Note that the modeling of 'self' with the current name lookup
mechanism is broken, so when ASTScope-based unqualified name lookup is
enabled, it fixes SR-2203, rdar://problem/16954496, and the many dupes
of the latter.
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.
That is, if a would-be witness to a protocol requirement is only
accessible because its module has been imported with '@testable',
consider that "good enough" to satisfy the rule that a witness
must be available everywhere the protocol and conforming type are
both available (because those other contexts /could/ have done their
own testable import).
rdar://problem/28173654
A throwing method can only be exposed to Objective-C if we can map the
return type convention, either because the return type is Void or
because it is something that is bridged to an object type (and can
therefore be nil to indicate error). Our predicate for checking
"bridged to an object type" didn't account for value types that are
exposed to (or come from) C, and therefore aren't actually bridged to
object types in the Objective-C thunk, meaning they cannot be
optional. An existing hack dealt with the largest class of
these---types like Int and Bool that can be dynamically bridged
to NSNumber---but generalize this by checking exactly how the result
type is going to be represented in Objective-C, rejecting '@objc' for
cases where the result type won't be an object type.
Fixes rdar://problem/28035614 for real.
Extend @objc inference for witnesses to also consider optional
protocols whose conformances come from superclasses. Because we don't
do real binding of witnesses for inherited conformances, this is a bit
of an heuristic, looking at whether the witness is a potential match
(vs. the known exact match), so it can infer @objc somewhat more
liberally than a complete solution.
Fixes rdar://problem/27348369.
Expand the scope of @objc inference for witnesses to encompass
witnesses that are in a different extension from that of the
conformance, including cases where one or the other is in the nominal
type declaration itself.
Fixes rdar://problem/26892526.
This might look like a regression in lazyness at first sight,
however this was previously being done implicitly by checking
the 'Self := Adoptee' substitution against the protocol's
generic signature, back when generic signatures had expanded
requirements for protocol associated types.
When generic signature minimization was switched on, this was
no longer being done, as a result it was possible to construct
code that would fail in the specializer with a missing
conformance.
When the call to checkGenericArguments() was removed from
ConformanceChecker::checkConformance(), we stopped recording
a dependency on the extended nominal type when checking an
extension that adds a protocol conformance to the type.
Fix this in a hacky way by recording an explicit dependency
in the same place where we used to call checkGenericArguments().
Surely this is not the best place for it though, so this
should be revisited since I'm pretty sure the old behavior
was an accident.
Now that the previous patches have shaken out implicit assumptions
about the order of generic requirements and substitutions, we can
make a more radical change, dropping redundant protocol requirements
when building the original generic signature.
This means that the canonical ordering and minimization that we
used to only perform when building the mangling signature is done
all of the time, and hence getCanonicalManglingSignature() can go
away.
Usages now either call getCanonicalSignature(), or operate on the
original signature directly.
When checking a conformance of a concrete type to a protocol, we
effectively checked the associated types twice -- once when
deriving them, and another time at the end, where we performed
a substitution of the protocol 'Self' type to the concrete type.
The latter checked superclass constraints, while the former did not.
However, this trick no longer works with minimized generic
signatures, because <P : Self> no longer has redundant requirements
for the associated types of 'P'.
Instead, check superclass constraints at the same time as checking
conformances.
