Found by inspection; a misplaced 'break' meant that, if we encountered
a relational constraint where both sides are type variables that are
equivalent, we would stop looking for more type bindings, which could
lead us to miss obvious type inferences. While I wasn't able to
construct a case where this changed the behavior of type inference,
this *does* happen, and the previous code was clearly wrong.
We previously allowed *any* conformance constraint to an
ExpressibleBy*Literal protocol to provide a default type (e.g.,
Int/Double/String/etc.) based on the kind of literal protocol. This
led to weird type inference behavior. Restrict the defaulting to
actual literals---not just conformances to literal protocols---which
is a much more reasonable rule.
Because this is a source-breaking change, only introduce this new
behavior when the Swift version >= 4, maintaining the old behavior in
Swift 3 compatibility mode.
The @objc optional requirement near-miss heuristics were too
permissive, and could occasionally produce ridiculous results that
were nowhere close to a "near" miss. Make the diagnostics more
conservative, and fix an issue with an errant sentinel value.
Fixes rdar://problem/26380688.
An overriding declaration doesn't have a choice about its signature,
because the signature is dictated by the overridden
declaration. Therefore, don't produce a warning for it.
Fixes rdar://problem/28524237.
When @objc inference was extended to look at the conformances of
superclasses, the code that diagnosed near misses was not similarly
updated, so we could end up producing a near-miss diagnostic on a
declaration that was already a witness to another protocol. Use the
same witness-finding logic that we use for @objc inference so this
doesn't happen again.
Fixes the rest of rdar://problem/27348369
Fixes: https://bugs.swift.org/browse/SR-2843
'P1 & P2.Type' is mistakingly accepted and parsed as (meatatype (composition P1, P2))
in swift3. Now, we parse it as (composition P1, (metatype P2))
For source compatibility, reconstruct it as Swift3.
Also, this solves inconsistent behavior between type and type-expression in Swift3.
typealias T1 = P1 & P2? // was accepted as '(P1 & P2)?'
let T2 = (P1 & P2?).self // was silently accepted as 'P1' in Swift3.0
Previously, non-IdentTypeRepr types are silently discarded.
'(P1? & P2.Type).self' ends up in empty protocol composition (aka 'Any').
Let CompositionType to hold them as well, and TypeChecker to diagnose them.
And make it be able to composite any TypeReprs.
Although Swift doesn't support composition of arbitrary types, AST
should be able to hold any TypeReprs, to represent syntax as accurate as
possible.
In usesTypeMetadataOfFormalType(), bail out if we're checking a cast and
the casted-to type is null or error_type. We would have already emitted
a diagnostic on the function body by this point and this avoids crashing
immediately after.
Suggestions on a better place for the test would be welcome. The crash
requires the cast to be in the body of a function in an NSObject-derived
cast.
Resolves rdar://problem/28583595.
Always check arguments of the tuple type against corresponding parameters,
otherwise for a single argument functions e.g. foo(_ a: Any) after SE-0046
type checker is going to produce incorrect solution.
The 'literalConformanceProto' field of
TypeVariableType::Implementation didn't take into account equivalence
classes of type variables. Eliminate it, and either look at the actual
expressions (for optimizing constraints during constraint generation)
or the actual constraints on a given type variable (for determining
whether to include optionals in the set of potential type variable
bindings).
(cherry picked from commit 6bdd9cfae5)
Sugared GenericTypeParamTypes point to GenericTypeParamDecls,
allowing the name of the parameter as written by the user to be
recovered. Canonical GenericTypeParamTypes on the other hand
only store a depth and index, without referencing the original
declaration.
When printing SIL, we wish to output the original generic parameter
names, even though SIL only uses canonical types. Previously,
we used to accomplish this by mapping the generic parameter to an
archetype and printing the name of the archetype. This was not
adequate if multiple generic parameters mapped to the same
archetype, or if a generic parameter was mapped to a concrete type.
The new approach preserves the original sugared types in the
GenericEnvironment, adding a new GenericEnvironment::getSugaredType()
method.
There are also some other assorted simplifications made possible
by this.
Unfortunately this makes GenericEnvironments use a bit more memory,
however I have more improvements coming that will offset the gains,
in addition to making substitution lists smaller also.
There's no point in adding the constraints known on an associated type
to the constraint system, because they're implied by the protocol
constraint itself.
UnconditionalAvailabilityKind => PlatformAgnosticAvailabilityKind
::UnavailableInCurrentSwift => ::SwiftVersionSpecific
Plus a couple related method renamings. Prep work for SR-2709.
The warnings here are not ideal, nor are the fixits, but having a
correct source location at least helps users determine where the
conversions are happening.
I've filed https://bugs.swift.org/browse/SR-2928 to improve the warnings
and fixits.
This resolves https://bugs.swift.org/browse/SR-2921 and the warning
location portion of rdar://problem/28722908.
This reverts commit 6bdd9cfae5. This
commit *appears* to be breaking something in Dollar involving
inference with array literals and 'nil'; pull it back for more
investigation.
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.
The 'literalConformanceProto' field of
TypeVariableType::Implementation didn't take into account equivalence
classes of type variables. Eliminate it, and either look at the actual
expressions (for optimizing constraints during constraint generation)
or the actual constraints on a given type variable (for determining
whether to include optionals in the set of potential type variable
bindings).
