Before, a keyword in an inheritance clause would lead to a long list of errors
not really showing what was wrong.
A special case is added to handle protocol composition; in inheritance clauses
the protocols don't have to be composed with 'protocol<>'.
Initializers are inherited by synthesizing an implicit decl which
delegates to super.init(). Previously this was only done if the
class and superclass were concrete.
The only thing missing was that we weren't computing an interface
type for the synthesized constructor. There are two steps to this:
- First, we must map the contextual types of the superclass
initializer's ParamDecls to the subclass generic context.
- Second, we must set the interface type by calling the new
configureInterfaceType() method, extracted from from
validateGenericSignature().
Note that configureInterfaceType() now uses the new
AbstractFunctionDecl::hasThrows() flag to set the 'throws' bit on
the function type. Previously, validateGenericFuncSignature()
would look at getThrowsLoc().isValid(), which is not correct for
imported, implicitly-generated or de-serialized decls that 'throw',
because none of those have source location information.
We still don't allow inheriting initializers which have their
own generic parameter list, like 'init<T>(t: T) {...}'. That
requires a little bit more refactoring.
Progress on <rdar://problem/23376955>.
BoundGenericType::getSubsitutions() would only look at the bound
generic arguments of the innermost type, ignoring parent types.
However, it would then proceed to walk the AllArchetypes list
of all outer generic parameter lists when forming the final
result.
The gatherAllSubstitutions() would also walk through parent types.
As a result, outer generic parameters would appear multiple
times.
Simplify gatherAllSubstitutions() to just skip to the innermost
BoundGenericType, and delegate to getSubsitutions() for the rest.
Most calls to gatherAllSubstitutions() are from SILGen it seems,
and fix only fixes one compiler_crasher.
However an upcoming patch adds a new call to gatherAllSubstitutions()
which caused some crashers to regress, so I'm going to fix it
properly here.
This particular crasher very rarely didn't crash, causing mayhem with
false failures on the builders.
We were keeping a reference to a vector that could be reallocated in a
recursive call back into the same function. Instead, tend towards
looking up the vector in the map each time we need it.
Don’t try to find a conformation witness for typealias declarations in
protocols.
Fixed a bug with same type constraint between an alias and a concrete
type - just a bad assumption on my part. Added test for that.
Made archetype builder more resilient in constructing PA trees: it will
work correctly now if the alias destination is a dependent member type
instead of an archetype type. It also handles the case of finding
multiple aliases with the same name along with an associatedtype with
that name, fixing up all the representative ptrs.
Extensions/Nominals that tried to use a protocol's typealias would get a
dependent type as resolved with the protocol's base instead of with the 'Self'
base type of the current extension/nominal, resulting in spurious conformance
failures. So resolve aliases to protocol assoctypes based on the 'Self'
in which they are used.
Also fixed tests to not use common stdlib names, added tests for
typealias in protocol extension and self & recursive aliases. One recent
crasher also fixed.
If the resulting function type contains an ErrorType, this is an indicator that
something else is wrong. Bail out in this case.
This happened if an enum case was referenced inside the where-clause and treated
as a type.
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.
