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.
In Swift 4 mode, no longer consider e.g. 'nsNumber as Int' or 'nsValue as NSRange' to be valid coercions. This would break compatibility with Swift 3, so in Swift 3 mode, accept the coercion, but *also* accept a checked cast without a warning, and raise a migration warning about the unchecked coercion.
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.
Refactor TypeChecker::checkGenericArguments to enable it
to be used by FailureDiagnosis::diagnoseArgumentGenericRequirements,
which consolidates requirement checking in one place.
Commit 170dc8acd7 removed a penalty that
we used to have for conversions to Any. In some unusual circumstances
not having that penalty can result in new amiguities where we should
have nothing ambiguous about an expression according to our type rules.
This change attempts to ensure that we make that less likely or
impossible by not allowing direct conversions from IUOs to Any (instead
forcing these to first be force-unchecked, leading to more expensive
solutions). We never should have allowed these conversions anyway,
independent of removing the penalty for conversions to Any.
This change is intentionally very narrow to avoid further potential
source breakage.
Fixes rdar://problem/29907555.
