Copy, Borrow, {Any, Optional}Try, VarargExpansion expressions
have to perform the same transformation - resolve the type and
use it to coerce their sub-expression. This change introduces a
single method to do just that instead of copying the same code
around.
Since `try!` now forces l-value -> r-value conversion during
CSGen, let's simplify solution application to `try` expressions
by coercing sub-expression to a type of a `try` itself which
would introduce all necessary loads.
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.
This appears to only support synthesized conformances because
operators in such cases use different names - `__derived_*`.
These days devirtualization like this is performed as part of
mandatory inlining. And this approach doesn't stack well with
features like `MemberImportVisibility` because there is change
to check whether witness is available or not.
This means we now either produce a bare ErrorType, or an ErrorType
with a generic parameter original type for a generic parameter hole.
We ought to further consolidate this logic by sinking the generic
parameter original type replacement into `simplifyType` itself, but
I'm leaving that for a future patch since it affects completion
results and I want to try keep this close to NFC.
Generic methods declared in protocols (and extensions thereof) cannot
be used on existential values, because there is no way to specialize
them for all potential types. Diagnose such cases in Embedded Swift
mode and via `-Wwarning EmbeddedRestrictions`.
This adds a bunch more warnings to the standard library that we'll
need to clean up, probably by `#if`'ing more code out.
Part of rdar://119383905.
It could be that refTy->hasDynamicSelfType() is true whereas
varDecl->getValueInterfaceType()->hasDynamicSelfType() is false.
This happens if the base of the access is dynamic Self, so the
refTy is (Self) -> @lvalue Int or whatever.
Note that replaceDynamicSelfType() behaves correctly in this case;
it leaves that Self in place, because it's in contravariant
position.
However, the other place where we check the condition would then
form a nonsensical CovariantReturnConversionExpr around the result
of the access, even though no conversion was necessary here; the
type of the returned value does not involve Self.
Simplify this logic further with the correct condition.
Fixes rdar://159531634.
Turns out we don't always set a completion callback for some unqualified
completion positions. Upgrade the check for a completion callback to
a check for a completion buffer to account for this. This avoids
unnecessary type-checker work as well as fixing a couple of
double-type-checking crashers.
