This exposes some wierdness with while_parsing_as_left_angle_bracket where
one case the note is being is when resolveType returns a failure. However,
resolveType can produce a failure without emitting a diagnostic, and this
can lead to us generating a note unattached to an error. Just remove this
case.
Set type repr's as invalid after diagnosing an unsupported protocol
to stop duplicate diagnoses.
There were two causes here. First, top-level variable
declarations were being checked once by the Decl checker, and then
again by the Stmt checker. (This caused SR-38.)
Second, the Stmt checker is called by an AST visitor itself, which
already calls it once per statement. Using the
UnsupportedProtocolVisitor here meant that each interior sub statement
would get visited multiple times. Added a setRecurseIntoSubstatements()
on the visitor, and set it to false for the Stmt checker. This keeps
from revisiting statements multiple times.
The idea here is to do more marking of the generic parts of the
protocol as being invalid as soon as the recursiveness is diagnosed in
order to simplify checking (and avoid infinite loops) down the line.
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.
Having bound types in TypeReprs causes trouble in several places
(mostly involving type-checking of generics), and doesn't really fit
with TypeReprs being a mostly syntactic construct. Eliminate some code
paths using getBoundType(), and make the others do the same thing for
getBoundDecl() and getBoundType(). As part of the latter, provide
TypeBase::getDirectlyReferencedTypeDecl() to more easily map from type
to the named declaration.
Swift SVN r32018
We have to check for cycles of length > 1 here. Also, add a bit to the
AssociatedTypeDecl to ensure the recursive requirement diagnostic is
only emitted once.
Fixes <rdar://problem/17986597>.
Swift SVN r30678
Reduces the number of duplicate diagnostics down to 2. Which is still
lame, but it's due to a different underlying issue. Finishes
rdar://problem/20682090.
Swift SVN r30043
Replace some dodgy recursion-breaking code in the archetype builder
that was meant to deal with recursive associated type requirements
(which our model does not currently support) with a more robust
approach. Fixes rdar://problem/20682090 and rdar://problem/21738889.
Swift SVN r30039
var/let bindings to _ when they are never used, and use some values that
are only written. This is a testsuite cleanup, NFC. More to come.
Swift SVN r28406
Having semantic checking in type validation introduces the potential for more recursion, triggering crashes. By moving this semantic restriction out to a later stage, we make it more robust. Fixes 6 compiler crashers, although it regressed one compiler crasher that hits a different known issue (assertions in addGenericParameters when we have multiple parameters at the same depth).
Swift SVN r26226
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
This can only occur when validating mutually recursive existentials in type reference expressions, so it's "safe" to avoid validating member value decls in this case. There are still potential holes in our mechanism for checking for unsupported existentials, but at least this will eliminate another common crasher. (Crash suite scenario 010.)
Swift SVN r22035
When trying to implement deduplication of results, found and fixed an issue
with loose checks for generic overload checking.
rdar://17995317
Swift SVN r21276
These changes prevent a certain class of bogus errors, as well as several crashers. Unfortunately, though, they don't quite get us to the point where we can broadly use recursively defined protocol requirements, in the standard library. (To do so would require significant changes across the entire stack.)
Swift SVN r19019
