- rdar://169975618 ([nonescapable] Type conversion for function types with lifetime dependencies)
- rdar://160970376 ([nonescapable] [type checker] [source compat] protocol requirements should require matching methods signatures, including @lifetime)
The previous logic was relying on doing `coerceCallArguments` with the
full argument list instead of only the non-trailing args, and wasn't
handling the non-shorthand-init case. Update the logic to fix-up the
apply during the pre-walk, ensuring it gets applied consistently.
rdar://170076966
If a partial application captures any non-`SendableMetatype` type parameter,
then it can call methods that are isolated to the current context and so the
function value cannot be `@Sendable`.
Resolves: rdar://170475422
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.