This appears unnecessary and incorrectly meant the ErrorExpr would
be placed outside the condition, meaning we could find the binding
in its own initializer.
Make sure we invalidate when we initially visit the ExprPattern to
ensure that we don't run into issues when generating constraints for
a `where` clause before the constraints for the ExprPattern. We ought
to change the constraint generation there to use a conjunction to
ensure that the pattern is solved before the `where` clause, but I
want to keep this as a quick low risk fix that we can cherry-pick. I'll
switch it to a conjunction in a follow-up.
Make sure we preserve the result expression for an out-of-place
`return`, or a non-`nil` result in an initializer. This ensures we
can still provide semantic functionality from them and fixes a crash
where we would fail to type-check a binding.
We know this is where the issue is so we can immediately bind to a hole,
ensuring we don't produce unnecessary downstream diagnostics from
things we can't infer.
The existing check is no-op because it would never produce a null for
`paramType` under the conditions in `else` branch. A better
API it use here is `conformsToKnownProtocol` just like in other cases.
Make sure we only ever type-check the `do` body of a `do-catch`
statement when lazily type-checking the bound error type, which we can
do for completion.
rdar://164481242
Make sure we query the constraint system for a type if we have a local
property wrapper in a closure to avoid kicking interface type
computation outside the closure, and make sure we map into context if
we need to.
And make sure we mark any PatternBindingDecl entries as having
been checked to avoid re-checking. This fixes a crash where we could
attempt to re-check a property wrapper to compute its backing type.
Support pack expansion types in term rewriting, maintaining shape invariants and not
throwing assertions unnecessarily.
Additional tests added for an inifinite case and a concrete case.
The change in 8ab8b2e3e9, was too
broad. We want to coerce the subexpression of `try!` to an rvalue,
but not the subexpression of a `try`.
If the subexpression of a `try` becomes an rvalue even though the
type of the parent expression is an lvalue, we can end up with
infinite recursion in coerceToType(), as demonstrated by the
test case.
Fixes https://github.com/swiftlang/swift/issues/85034.
Update special favoring logic for unlabeled unary calls to support
non-overloads member references in argument positions.
The original hack missed a case where a type of a member is known
in advance (i.e. a property without overloads) because there as
another hack (shrink) for that.
This helps in situations like `Double(x)` where `x` is a property
of some type that is referenced using an implicit `self.` injected
by the compiler.
Resolves: rdar://161419917
We already reject attempts to reference this for `lazy` properties.
For `lazy` locals let's just not expose it to name lookup to begin
with. This ensures we don't attempt to prematurely kick the interface
type computation for the var, fixing a couple of crashers.
