This time, the issue is that TypeNullifier skips bodies of
multi-statement closures. However, ExprRewriter will type
happily pass them on to typeCheckClosureBody(). This could
trigger assertions. Fix this by skipping type checking of
multi-statement closures when diagnosing.
There seems to be a minor QoI regression in some test cases
that already looked pretty dodgy and/or had FIXMEs. However
I think its worth fixing a crash.
This crashing test became non-crashing in #138. #138 also emitted multiple instances of the same diagnostic, which was causing -verify to fail on decl/protocol/req/recursion.swift.
These APIs are from the Swift 1.2 => Swift 2.0 transition, and are not
relevant anymore.
Removing them reduces the surface area of the library that needs to be
reviewed.
When typo-correcting a potential archetype (i.e., a nested name
T.foo), record the rename within the potential archetype but don't
consider the signature to be invalid. Move the actual typo-correction
diagnostics and AST fix-ups outside of the archetype builder, so we
get proper Fix-Its and a correct generic signature. Fixes
rdar://problem/20789924.
Swift SVN r32677
This is all effectively NFC, but lays out the shape of the iterative
type checker: requests are packaged up in TypeCheckRequest, we can
check whether the request has been satisfied already (isSatisfied),
enumerate its dependencies (enumerateDependenciesOf) in terms of other
TypeCheckRequests, and satisfy a request (satisfy).
Lazily-computed semantic information is captured directly in the
AST, but has been set aside in its own structure to allow us to
experiment with moving it into a lookaside table.
The only request that exists now is to type-check the superclass of
the given class. It currently performs unhealthy recursion into the
existing type checker. As we detangle dependencies, this recursion
between the IterativeTypeChecker and the TypeChecker can go away.
Swift SVN r32558
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
The conformance lookup table is responsible for answering queries
about the protocols to which a particular nominal type conforms, so
stop storing (redundant and incorrect) protocol lists on the ASTs for
nominal types. Protocol types still store the list of protocols that
they inherit, however.
As a drive-by, stop lying about the number of bits that ProtocolDecl
uses on top of NominalTypeDecl, and move the overflow bits down into
ProtocolDecl itself so we don't bloat Decl unnecessarily.
Swift SVN r31381
The getConformsTo() callback was responsible for forcing the
collection of the requirements directly placed on an associated type,
which then get added to the archetype builder. This resulted in an
unhealthy dependency on the list of protocols attached to TypeDecl
(which should go away). Instead, retrieve the requirements from the
associated type's archetype (once it's been computed) or directly from
its list of "inherited" types (while we're building the generic
signature for the protocol itself).
Swift SVN r31332
the regressions that r31105 introduced in the validation tests, as well as fixing a number
of other validation tests as well.
Introduce a new UnresolvedType to the type system, and have CSDiags start to use it
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31130
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
- When we walk up through parent types of 'this', we also have to walk up
the parent contexts of 'gpContext', otherwise an assertion fires.
- getSuperclass() needs to map generic type parameters of the parent
type even if the superclass is not generic.
Swift SVN r30676
