Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
Cleans up AST printing somewhat as well as providing slightly better
type-to-declaration mappings for annotated AST printing and indexing.
Swift SVN r32420
The exact message is mostly immaterial at this point, but without the
change we end up recursively validating the property, marking it invalid,
and then never actually emitting a diagnostic, leaving SILGen and
Serialization to go ahead and fail.
rdar://problem/20913392
Swift SVN r30830
This reverts revision r30688. The patch needs more work, because it flags a
valid case as circular, see r15054, "Relax restriction on indirectly-self-
recursive protocol conformances. (rdar://problem/16306715)".
Swift SVN r30690
- In name lookup, if we find a decl that is already being type checked
(which only occurs on illegal code) just assume it is acceptable instead
of blowing up with an assertion checking access control that hasn't been
evaluated yet.
- In checkInheritanceClause, make sure that the we mark the decl being
resolved as being type checked when resolving the types involved. That way,
cyclic references are detected as invalid, instead of causing assertions and
other explosions.
This fixes some compiler crashers.
Swift SVN r29538
It’s real intent is to check only the generic signature of the DeclContext provided to name lookup, then enclosing contexts. Use it for functions and initializers as well, so we have uniform lookup behavior for entities that can have generic parameters.
A follow-up commit contains some minor, semi-related tweaks along with a pile of updates to the compiler crash testsuite.
Swift SVN r26654
This seems to already be working for variables in trunk, so it's just
functions that need the fix. (I'm not sure why the variables are emitting
the error twice, but I'm not going to spend time on that right now.)
rdar://problem/19715729
Swift SVN r25276
