Filter out any duplicate notes to help cut down on the noise for
request cycle diagnostics. Some of the note locations here still aren't
great, but this at least stops us from repeating them for each
intermediate request.
Every protocol gets an 'identity conformance' rule [P].[P] => [P].
A trivially-stated circularity is always redundant because of this
rule, and we diagnose circular inheritance elsewhere as a hard
error, so just add a special case to skip adding such a rule here
to avoid the useless warning on top of the existing error.
Rather than relying on clients to cope with the potential for circular
inheritance of superclass declarations, teach SuperclassDeclRequest to
establish whether circular inheritance has occurred and produce "null"
in such cases. This allows other clients to avoid having to think about
To benefit from this, have SuperclassTypeRequest evaluate
SuperclassDeclRequest first and, if null, produce a Type(). This
ensures that we don't get into an inconsistent situation where there
is a superclass type but no superclass declaration.
* [Sema] Factor out shouldAttemptInitializerSynthesis
This makes sure we don't attempt to synthesize
a memberwise or default initializer for an invalid
decl, or one in a module interface.
* [Sema] Requesify inheritsSuperclassInitializers
This commit introduces a request for computing
whether a class inherits both designated and
convenience initializers from its superclass.
The shared logic of finding initializers which the
subclass hasn't overriden has been factored out
into `collectNonOveriddenSuperclassInits`.
* Cleanup addImplicitInheritedConstructorsToClass
This commit removes some code that's no longer
needed. In addition, now that we've requestified
`inheritsSuperclassInitializers`, we can directly
diagnose on non-inherited required convenience
inits within the loop.
* Inherited init synthesis no longer deals with clang decls
Now that the computation of
`inheritsSuperclassInitializers` has been split off
into a request, we can avoid calling
`addImplicitInheritedConstructorsToClass` for clang
decls.
* Address review feedback
Continue to cache the InheritsSuperclassInits bit
on the AST.
ClassDecl::getSuperclass() produces a complete interface type describing the
superclass of a class, including any generic arguments (for a generic type).
Most callers only need the referenced ClassDecl, which is (now) cheaper
to compute: switch those callers over to ClassDecl::getSuperclassDecl().
Fixes an existing test for SR-5993.
Introduce a command-line option to visualize the complete set of output
request dependencies evaluated by a particular compile action. This is
exposing existing visualization facilities to the (-frontend) command line.
When dumping dependencies, clean up the output in two ways:
* Elide redundant but (non-cyclic) references to the same dependency.
* When dumping a cycle, highlight the path to the cycle so it stands out.
As a debugging aid, introduce a new frontend flag `-debug-cycles` that
will emit a debug dump whenever the request-evaluator encounters a cyclic
dependency, while otherwise allowing compilation to continue.
Wire up the request-evaluator with an instance in ASTContext, and
introduce two request kinds: one to retrieve the superclass of a class
declaration, and one to compute the type of an entry in the
inheritance clause.
Teach ClassDecl::getSuperclass() to go through the request-evaluator,
centralizing the logic to compute and extract the superclass
type.
Fixes the crasher from rdar://problem/26498438.
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
