We had four duplicated implementations of checking how a protocol
requirement uses 'Self', all slightly wrong or incomplete:
- When deciding if the protocol type can be used as an existential.
This one would just ignore 'Self' in the return type of a method
completely, which was incorrect for cases where 'Self' is
contravariant but part of the return value, for example:
func foo() -> (Self -> ())
- When deciding if a member access can be performed on an existential
value. This is distinct from the former, because the member may
have been defined in a protocol extension, in which case it cannot
be used even if the protocol type can be used as an existential.
Unfortunately, this implementation was overly conservative, and
would reject uses of 'Self' where Sema could in fact erase the
existential type, for example:
func foo() -> Self??
func foo() -> Self.Type
func foo() -> (Self, Self)
This function handled function return types correctly, effectively
plugging the leak in the previous code. It did lead to inconsistent
behavior with protocols that had contravariant Self in requirements
though; sometimes we would diagnose uses of the existential type,
other times we would only complain about specific members.
- When deciding if a method in a non-final class can model a protocol
requirement. This one was the most elaborate one, but here
contravariance and uses of associated types are actually okay, so
it was written to pick up covariant 'Self' only. However, it also
did not handle metatypes and tuples.
- When opening the type of member of an existential, we would check
if the return value was 'Self' or an optional of 'Self', but again
this check was too conservative, so after the previous three were
fixed, we could reference members on existentials that did not
have a correct opened type.
Now, these have been combined into one check. To fix some crashes,
Sema's implementation of erasing existentials now relies on
coerceToType() instead of hand-rolling a few coercions of its own,
and wrapping the rest in CovariantFunctionConversionExpr, which
didn't make much sense if the result was not a function type.
SILGen still does not support function type conversions where an
existential return value is being erased; these would silently
miscompile before, but crash with an assertion now, because they
are correctly modeled as a FunctionConversionExpr, and not
CovariantFunctionConversionExpr.
There was a diagnostic to catch these, but it wasn't triggered
reliably, and it sounds like users were already relying on this
feature working in the few cases where it did.
So instead, just map an archetype's superclass into context
when building the archetype.
Recursion is still not allowed and is diagnosed, for example
<T, U where T : C<U>, U : C<T>>.
Note that compiler_crashers_fixed/00022-no-stacktrace.swift no
longer produces a diagnostic in Sema, despite the fact that the
code is invalid. It does diagnose in IRGen when we map the
type into context. Diagnosing in Sema requires fixing the
declaration checker to correctly handle recursion through a
generic signature. Right now, if recursion is detected, we bail
out, but do not always diagnose. Alternatively, we could
prohibit unbound generic types from appearing in generic
signatures.
This is a more principled fix for rdar://problem/24590570.
In some completely insane cases, typechecking an EnumElementDecl
can recursively reference itself. Make sure to produce an error
and bail out when this happens.
Not all types are l-valuable, notably InoutType's. This seems like a
weird restriction to put in the type checker, but it is the cleanest
solution to this. The better solution would be to change how
inoutexpr/inouttype are represented completely... maybe someday.
Formerly we stopped type checking a PatternBindingDecl when it was marked
as invalid. This prevented semantic analysis from doing things like expanding
"stored" properties in protocols into computed properties with getters and setter,
causing downstream problems.
Stop doing this, and instead do a bit of work to silence the downstream errors in
a more narrow way.
The problem was that an associated type was always resolved with the nearest protocol `Self` as a reference, but in the case of nested protocols the associated type might be from the enclosing protocol leading to a crash.
We now enumerate in a bottom-up way through the contexts until we have found the correct protocol which provides us with the `Self` reference to resolve the associated type.
closures which have already been transformed into void conversion closures.
This fixes 28213-swift-expr-walk.swift/28187-llvm-foldingset-swift-constraints-constraintlocator.swift
