It's always been the case that partial solutions introduce
some storage duplication when applied back to the constraint
system to form a more complete solution with outer context,
but the constraint systems used to be small before
introduction of result builders (and now multi-statement
inference), which make the duplication more visible.
When a closure is provided with a contextual type that has isolated
parameters, infer that the corresponding closure parameter is "isolated".
Fixes rdar://83732479.
The current IUO design always forms a disjunction
at the overload reference, for both:
- An IUO property `T!`, forming `$T := T? or T`
- An IUO-returning function `() -> T!`, forming `$T := () -> T? or () -> T`
This is simple in concept, however it's suboptimal
for the latter case of IUO-returning functions for
a couple of reasons:
- The arguments cannot be matched independently of
the disjunction
- There's some awkwardness when it comes e.g wrapping
the overload type in an outer layer of optionality
such as `(() -> T!)?`:
- The binding logic has to "adjust" the correct
reference type after forming the disjunction.
- The applicable fn solving logic needs a special
case to handle such functions.
- The CSApply logic needs various hacks such as
ImplicitlyUnwrappedFunctionConversionExpr to
make up for the fact that there's no function
conversion for IUO functions, we can only force
unwrap the function result.
- This lead to various crashes in cases where
we we'd fail to detect the expr and peephole
the force unwrap.
- This also lead to crashes where the solver
would have a different view of the world than
CSApply, as the former would consider an
unwrapped IUO function to be of type `() -> T`
whereas CSApply would correctly see the overload
as being of type `() -> T?`.
To remedy these issues, IUO-returning functions no
longer have their disjunction formed at the overload
reference. Instead, a disjunction is formed when
matching result types for the applicable fn
constraint, using the callee locator to determine
if there's an IUO return to consider. CSApply then
consults the callee locator when finishing up
applies, and inserts the force unwraps as needed,
eliminating ImplicitlyUnwrappedFunctionConversionExpr.
This means that now all IUO disjunctions are of the
form `$T := T? or T`. This will hopefully allow a
further refactoring away from using disjunctions
and instead using type variable binding logic to
apply the correct unwrapping.
Fixes SR-10492.
FunctionInput relies on being able to represent
parameter lists as tuples, which won't be possible
once parameter flags are stripped from tuple types.
FunctionResult is reasonable, but is currently
unused.
Attempting to pre-compute a set of referenced type variables
upfront is incorrect because parameter(s) and/or result type
could be bound before conjunction is attempted. Let's compute
a set of referenced variables before each element gets attempted.
Let's delay solution application to multi-statement closure bodies,
because declarations found in the body of such closures may depend
on its `ExtInfo` flags e.g. no-escape is set based on parameter if
closure is used in a call.
A contextual purpose for a sequence expression associated with
`for-in` statement, that decays into a `ConformsTo` constraint
to a `Sequence` or `AsyncSequence` protocol.
Note that CTP_ForEachSequence is almost identical to CTP_ForEachStmt
but the meaning of latter is overloaded, so to avoid breaking solution
targets I have decided to add a new purpose for now.
Iterate over all of the elements one-by-one and make sure that
each results in a single solution, otherwise fail the conjunction step.
Once all of the elements are handled either stop or,
if conjunction step has been performed in isolation,
return all of the outer constraints back to the system
and attempt to solve for outer context - that should
produce one or more solutions for conjunction to be
considered successfully solved.
This commit refactors the way ASTs are being built in SourceKit and how `SwiftASTConsumer`s are served by the built ASTs. `SwiftASTManager.h` should give an overview of the new design.
This commit does not change the cancellation paradigm in SourceKit (yet). That is, subsequent requests with the same `OncePerASTToken` still cancel previous requests with the same token. But while previously, we were only able to cancel requests that haven’t started an AST build yet, we can now also cancel the AST build of the to-be-cancelled requests.
With this change in place, we can start looking into explicit cancellation of requests or other cancellation paradigms.
for unapplied references when the choice is a function declaration.
This will allow the solver to prune those overload choices when it
has already found a solultion with a property (all else equal in the
score). This is already done as an ambiguity tie-breaker in solution
ranking, but adding this bit to the score will prune a lot of search
space within the solver.
Instead of passing pattern directly, let's fetch it from the pattern
binding and remove extra argument from `SolutionApplicationTarget::forUninitializedVar`.
- Explicitly limit favoring logic to only handle
unary args, this seems to have always been the
case, but needs to be handled explicitly now that
argument lists aren't exprs
- Update the ConstraintLocator simplification to
handle argument lists
- Store a mapping of locators to argument lists
in the constraint system
- Abstract more logic into a getArgumentLocator
method which retrieves an argument-to-param locator
from an argument anchor expr
Detect situations when type of a declaration hasn't been resolved yet
(one-way constraints would use a type variable to represent a type of IUO pattern),
and use additional type variable and a constraint to represent an
object type of a future optional type.
Resolves: SR-14893
Resolves: rdar://80271666
This is a follow-up to the uninitialized variable generalization.
Pattern binding declaration has to be stored together with the
variable because all of the entries in `SolutionApplicationTarget`
form a union.
`SolutionApplicationTargetsKey` was constructing pattern binding
entries with incorrect `kind`, which led to crashes for pattern
bindings with multiple initialized entries.
