The general self-derived check doesn't really make sense for
conformance constraints, because we want to distinguish among
different protocol conformances.
The list of directly inherited protocols of a ProtocolDecl is already
encoded in the requirement signature, as conformance constraints where
the subject is Self. Gather the list from there rather than separately
computing/storing the list of "inherited protocols".
Previously, validateDecl() would check if the declaration had an
interface type and use that as an indication not to proceed.
However for functions we can only set an interface type after
checking the generic signature, so a recursive call to validateDecl()
on a function would "steal" the outer call and complete validation.
For generic types, this meant we could have a declaration with a
valid interface type but no generic signature.
Both cases were problematic, so narrow workarounds were put in
place with additional new flags. This made the code harder to
reason about.
This patch consolidates the flags and establishes new invariants:
- If validateDecl() returns and the declaration has no interface
type and the isBeingValidated() flag is not set, it means one
of the parent contexts is being validated by an outer recursive
call.
- If validateDecl() returns and the declaration has the
isBeingValidated() flag set, it may or may not have an interface
type. In this case, the declaration itself is being validated
by an outer recursive call.
- If validateDecl() returns and the declaration has an interface
type and the isBeingValidated() flag is not set, it means the
declaration and all of its parent contexts are fully validated
and ready for use.
In general, we still want name lookup to find things that have an
interface type but are not in a valid generic context, so for this
reason nominal types and associated types get an interface type as
early as possible.
Most other code only wants to see fully formed decls, so a new
hasValidSignature() method returns true iff the interface type is
set and the isBeingValidated() flag is not set.
For example, while resolving a type, we can resolve an unqualified
reference to a nominal type without a valid signature. However, when
applying generic parameters, the hasValidSignature() flag is used
to ensure we error out instead of crashing if the generic signature
has not yet been formed.
This leads to some bad recursion through validateDecl(), even
when called from the ITC. We already had machinery to add
implicit constructors later, it just had to be extended to
do it for the superclass as well.
The code would generate different diagnosics depending on
the cycle having length 1 or longer. The length 1 case
was broken if the path had a prefix that wasn't part
of the cycle, eg if we have C : A, A : A and visit C
first.
Swift SVN r28317
Replace the loop over all known protocols with a query into the
actual conformance lookup table, which more properly deals with
out-of-order conformance queries, inheritance of protocol
conformances, and conformance queries in multi-file situtations.
The SILGen test change is because we're no longer emitting redundant
conformances, while the slight diagnostic regression in
circular-inheritance cases is because we handle circular inheritance
very poorly throughout the compiler.
While not the end, this is a major step toward finishing
rdar://problem/18448811.
Swift SVN r26299
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Break cycles agressively when we find circular class inheritance. The
stronger AST invariants prevent us from having to check for loops
everywhere in the front end.
Swift SVN r7325
