Rather than mutating the parameter pattern in place and separately
return whether an error occurred, return the new pattern or NULL if an
error occurred. While here, switch over to ContextualPattern for the
input.
And get rid of that infernal "goto".
Compute the "raw" type of a pattern via a request, caching the result
of TypeChecker::typeCheckPattern(). Retain typeCheckPattern() as the
general entrypoint for performing this computation so that other code
doesn't need to change yet.
Contextual pattern describes a particular pattern with enough
contextual information to determine its type. Use this to simplify
TypeChecker::typeCheckPattern()'s interface in a manner that will
admit request'ification.
The diagnostic is still terrible, but at least we shouldn't crash.
Fixes one manifestation of <rdar://problem/57726880>.
I also filed <https://bugs.swift.org/browse/SR-11989> to track improving
the diagnostic.
Make TypeChecker::typeCheckPattern() return the computed type, rather
than returning an "error" flag. More importantly, make it functional,
so that it doesn't set the type it computes on the pattern.
Use UnresolvedType as a placeholder for types that need to be
inferred, rather than a null type. This allows us to produce
structural types involving types that need to be inferred.
Note that with this change as-is, we get a number of duplicated
diagnostics, because typeCheckPattern() will be called multiple times
for the same pattern and will emit some diagnostics each time. This
will be addressed in a subsequent commit.
There are certain conditions that cause them to reference
non-public properties, in particular if the property
wrapper is implemented via a subscript taking a keypath.
Instead of trying to detect this specific case though (and
possibly missing others), I'm just going to decree that
'modify' is never going to be transparent for property
wrappers.
Fixes <rdar://problem/57609867>.
Move the various "application" logic for the for-each loop out of the
visitor in TypeCheckStmt and into the constraint system's handling of
for-each bindings.
Rather than having the type checker look for the specific witness to
next() when type checking the for-each loop, which had the effect of
devirtualizing next() even when it shouldn't be, leave the formation
of the next() reference to SILGen. There, form it as a witness
reference, so that the SIL optimizer can choose whether to
devirtualization (or not).
Rather than having the type checker form the ConcreteDeclRef for
makeIterator, have SILGen do it, because it's fairly trivial.
Eliminates some redundant state from the AST.
To check if the completion is happening in the AFD body.
Otherwise, local variables are sometimes not suggested because the body
and its range is from another file.
rdar://problem/58175106
Introduce a new kind of constraint, the "value witness" constraint,
which captures a reference to a witness for a specific protocol
conformance. It otherwise acts like a more restricted form of a "value
member" constraint, where the specific member is known (as a
ValueDecl*) in advance.
The constraint is effectively dependent on the protocol
conformance itself; if that conformance fails, mark the type variables
in the resolved member type as "holes", so that the conformance
failure does not cascade.
Note that the resolved overload for this constraint always refers to
the requirement, rather than the witness, so we will end up recording
witness-method references in the AST rather than concrete references,
and leave it up to the optimizers to perform devirtualization. This is
demonstrated by the SIL changes needed in tests, and is part of the
wider resilience issue with conformances described by
rdar://problem/22708391.
The type checking of the for-each loop is split between the constraint
solver (which does most of the work) and the statement checker (which
updates the for-each loop AST). Move more of the work into the constraint
solver proper, so that the AST updates can happen in one place, making use
of the solution produced by the solver. This allows a few things, some of
which are short-term gains and others that are more future-facing:
* `TypeChecker::convertToType` has been removed, because we can now either
use the more general `typeCheckExpression` entry point or perform the
appropriate operation within the constraint system.
* Solving the constraint system ensures that everything related to the
for-each loop full checks out
* Additional refactoring will make it easier for the for-each loop to be
checked as part of a larger constraint system, e.g., for processing entire
closures or function bodies (that’s the futurist bit).
If a completion happens in an 'PatternBindingInitializer' context for
'TypedPattern' without any 'VarDecl', e.g.:
let _: Int = <COMPLETION>
it crashes because 'typeCheckPatternBinding()' requires that the
'TypedPattern' has the type.
rdar://problem/52105899
