ConstraintSystem::simplifyType() replaced types with their fixed types
from the global map.
Solution::simplifyType() replaced types with their fixed types from the
current bindings.
There were some minor differences between the two, and some dead code.
These are never part of an @objc protocol, so we shouldn't bother
looking for them and certainly shouldn't expect them to be there.
Fixes a crash introduced in 1f2121377.
rdar://problem/30101703
Now that NameAliasTypes desugar to interface types, it is possible
to have a protocol requirement type contain a NameAliasType which
contains an associated type:
protocol P {
associatedtype Element
typealias Elements = [Element]
func process(elements: Elements)
}
In Swift 3, the typealias would be desugared at name lookup time
in this case, but this is no longer the case, as a result associated
type inference stopped working in this example.
Fixes <https://bugs.swift.org/browse/SR-3641>.
If there are unresolved generic parameters present and we are trying
to diagnose problems related to initializer call, it makes sense to
check argument expression first, which might be erroneous and then move
on to the ambiguity checking instead of trying to lookup possible
constructors directly.
Start using this entrypoint when we have a specific associated
type. The eventual goal here is to create the invariant
resolveArchetype(t)->getDependentType()->isEqual(t)
when t has fully-resolved DependentMemberTypes.
Swift's language model doesn't guarantee that type metadata will ever really be used, which makes overriding initialize() error-prone and not really any better than manually invoking an initialization function. Warn about this for Swift 3 compatibility and reject attempts to override +initialize in Swift 4.
Constraint application had a "peephole" to try to generate a series of
optional-injection expressions when performing an optional-to-optional
coercion such as "Int??!" to "Int?????!". However, the computation
incorrectly selecting between implicitly-unwrapped optional and
optional types for intermediate steps, leading to an AST verification
failure. Clean up the implementation to use
TypeBase::lookThroughAllAnyOptionalTypes() rather than hand-rolled,
more-lossy versions and use the actual optional types in the "to" type
along each step, which has the side effect of maintaining type sugar.
1efafbcd9b restricted our classification
of various optional-related conversions (implicit forcing of IUOs,
optional-to-optional conversions, value-to-optional conversions) to
produce a single potential classification. However, in the presence of
type variables, we cannot always determine which particular conversion
restriction might apply. Prior to 1efafb, we produced too many
options; after 1efafb, we produced too few. Here, enumerate a more
bounded (but complete) set of potential conversions, taking into
account embedded type variables.
This is a better fix for rdar://problem/29977523 than simply reverting
1efafb, because it bounds the set of optional conversions we attempt.
Add additional checks before trying to re-check argument expression in
`FailureDiagnosis::diagnoseImplicitSelfErrors` and before trying to use
its resulting type, which can only be either tuple or paren type.
It's undesirable to have generic type which contains type variables
as contextual conversion type while diagnosing sub-expressions, it's
going to result in attempt to convert generic arguments to unresolved
type which produces worse diagnostics than no contextual type at all.
Resolves: SR-3525.
This reapply's Doug's change d79ba781c6,
which had previously been applied on top of
1efafbcd9b, the latter of which resulted
in a source compatibility break.
This reverts commit 1efafbcd9b because
results in a regression in source compatibility with Swift 3.
It also adds a test demonstrating what was broken by the change.
I will take another look at fixing the exponential behavior that this
was attempting to fix.
Fixes rdar://problem/29977523.
While shrinking constraint system, avoid candidates which contain
closures inside, because closure expressions require special handling
and allow no rollback.
Since `ConstraintSystem::shrink` is going to attempt to type-check
sub-expressions separately it's essential to clean-up AST if constraint
generation or solving of the such expressions fails, otherwise if
such solving resulted in creation of implicit expression type variables
might leak to the outside.
...instead of just ignoring the errors in certain cases, in service of
source compatibility.
Swift 3.0 wasn't nearly as strict as checking access control for types
because it didn't look at the TypeRepr at all (except to highlight a
particular part of the type in diagnostics). It also looked through
typealiases in certain cases. Approximate this behavior by running the
access checking logic for Types (rather than TypeReprs), and downgrade
access violation errors to warnings when the checks disagree.
Part of rdar://problem/29855782.
No functionality change; the value at the place where the callback is
invoked is always DowngradeToWarning::No. This will be exercised by
the next commit.
