Still record overload choices for `makeIterator` and `next` when
solving a `ForEachElement` constraint. This maintains compatibility
with the previous behavior where we would solve these in the constraint
system, since the choices can affect ranking if e.g Collection's
default `makeIterator` is compared with a concrete `makeIterator`
overload. This is a complete hack though and we ought to rip this out
as soon as we can.
rdar://168840696
If the base captured type still has type variables when we bind the
member function type, form a Sendable dependent function type with
the base type. This will then be eliminated by TypeSimplifier once
all the type variables in the base type have been resolved.
This then allows us to remove the delaying logic from member lookup.
We actually have to check this constraint, otherwise we accept invalid
code where we're referencing a protocol requirement with a concrete
base type which conditionally conforms to the protocol, but the
conditional requirements are unsatisfied.
However, we still need to skip it for AnyObject lookup, Distributed
Actors, and some weird edge case in conformance checking for isolated
conformances.
We should clean this up further later, but for now this closes a soundness
hole.
Fixes rdar://168129757.
We shouldn't store a pointer to the ConstraintSystem inside every
BindingSet, but there are some annoying things to untangle before
we can do that.
As a starting point toward that, remove the getConstraintSystem()
getter so that at least we can't reach up to the ConstraintSystem
from the outside.
We already had bookkeeping to track which statement in a multi-statement
closure we were looking at, but this was only used for the 'reasonable time'
diagnostic in the case that we hit the expression timer, which was almost
never hit, and is now off by default. The scope, memory, and trial limits
couldn't use this information, so they would always diagnose the entire
target being type checked.
Move it up from ExpressionTimer to ConstraintSystem, so that we get the
right source location there too. Also, factor out some code duplication
in BuilderTransform to ensure we get the same benefit for result builders
applied to function bodies too.
These methods can be simplified a bunch since the returned decl is
always the input decl and we can refactor the lambdas to just return
the auxiliary variable and have the type computation in the caller.
We ought to consider outright banning these conversions if the
destination is a generic parameter type, but for now let's penalize
them such that we don't end up with ambiguities if you're doing an
implicit pointer conversion through an identity generic function.
rdar://161205293
Hamish Knight
Kavon Farvardin
Slava Pestov
elsa
Elsa Keirouz
Pavel Yaskevich
Pavel Yaskevich
Mykola Pokhylets
Becca Royal-Gordon
Allan Shortlidge