The previous patches regressed a test where we used to diagnose
(poorly) a circular associated type, like so:
associatedtype e: e
With the error "inheritance from non-protocol, non-class type 'e'".
This error went away, because we end up not setting the interface
type of the associated type early enough. Instead, we return an
ErrorType from resolveTypeInContext() and diagnose nothing.
With this patch, emit a diagnostic at the point where the ErrorType
first appears.
Also, remove the isRecursive() bit from AssociatedTypeDecl, and
remove isBeingTypeChecked() which duplicates a bit with the same
name in Decl.
Extending this hack recovers a regression in a previously-fixed
compiler crasher (#26725), and fixes two more compiler crashers. So,
despite it's utter lack of principle, it's progress.
If a sugared type desugars to a substitutable type, we would
return the replacement type without the sugar. I think in
practice this meant that ParenType would be lost sometimes.
Preserving this correctly is required for an upcoming CSDiag
change.
Note that there's a minor source-breaking change with enum
case constructors here. I've filed <rdar://problem/27261929>
to track sorting it out in Swift 3 mode.
Also an upcoming patch fixes another related issue and adds more
tests for case constructors.
Previously, getInterfaceType() would return getType() if no
interface type was set. Instead, always set an interface type
explicitly.
Eventually we want to remove getType() altogether, and this
brings us one step closer to this goal.
Note that ParamDecls are excempt from this treatment, because
they don't have a proper interface type yet. Cleaning this up
requires more effort.
This handles situation when overload for the subscript hasn't been resolved
by constraint solver, such might happen, for example, if solver was allowed to
produce solutions with free or unresolved type variables (e.g. when running diagnostics).
Resolves: <rdar://problem/27329076>, <rdar://problem/28619118>, <rdar://problem/2778734>.
When a generic parameter list fails to parse, we don't call
DeclContext::setGenericParams(), even though the generic
parameters are still available for name lookup.
This causes various crashes, which this patch fixes by
mapping the generic parameters to ErrorTypes.
Previously, getInterfaceType() would return getType() if no
interface type was set. Instead, always set an interface type
explicitly.
Eventually we want to remove getType() altogether, and this
brings us one step closer to this goal.
Note that ParamDecls are excempt from this treatment, because
they don't have a proper interface type yet. Cleaning this up
requires more effort.
Since 'try' or '=' can be folded with type expression at the same time,
Shallow simplifyTypeExpr() results '->' being escaped from TypeChecker.
For instance:
try () -> Int
Used to crash the compiler.
Also, never return nullptr for ArrowExpr. `1 -> Int` is invalid anyway.
Instead of leave ArrowExpr as is, construct ErrorTypeRepr for '1' part.
For constructing the dummy expression for missing initializer,
use the end location of the pattern instead of the location of the
current token.
Previous behavior used to build AST like:
{ if let x [eof]
|---| Pattern range
|---| Dummy introducer range
|------------| IfStmt range
|--------| BraceStmt range
Now:
{ if let x [eof]
|---| Pattern range
| Dummy introducer range
|------| IfStmt range
|--------| BraceStmt range
On rare occasions, malformed programs can allow an UNCHECKED_EXPR (e.g. ArrowExpr) to escape type checking. The erroneous expression may have sub-expressions which aren't fully typechecked, so we can't safely visit them.
In the constraint solver, we've traditionally modeled nested type via
a "type member" constraint of the form
$T1 = $T0.NameOfTypeMember
and treated $T1 as a type variable. While the solver did generally try
to avoid attempting bindings for $T1 (it would wait until $T0 was
bound, which solves the constraint), on occasion we would get weird
behavior because the solver did try to bind the type
variable.
With this commit, model nested types via DependentMemberType, the same
way we handle (e.g.) the nested type of a generic type parameter. This
solution maintains more information (e.g., we know specifically which
associated type we're referring to), fits in better with the type
system (we know how to deal with dependent members throughout the type
checker, AST, and so on), and is easier to reason able.
This change is a performance optimization for the type checker for a
few reasons. First, it reduces the number of type variables we need to
deal with significantly (we create half as many type variables while
type checking the standard library), and the solver scales poorly with
the number of type variables because it visits all of the
as-yet-unbound type variables at each solving step. Second, it
eliminates a number of redundant by-name lookups in cases where we
already know which associated type we want.
Overall, this change provides a 25% speedup when type-checking the
standard library.
Rather than computing the requirement environment as a tuple of
(generic signature, generic environment, substitution map),
encapsulate the result in a new RequirementEnvironment
class. Moreover, create a RequirementEnvironment once and re-use it
when matching each of the witnesses, because the environment itself
doesn't change---only the substitutions do. This saves us some work
when there are multiple potential witnesses (which is common).
We've been performing the "occurs" check when computing potential
bindings for type variables, but we weren't actually performing the
check for bindings that *must* occur. Perform the occurs check before
binding type variables, which fixes a few crashers and is far more principled.
Note that this obviates the need for tracking the type variables we've
substituted in simplifyType(), so simplify that as well.
Fixes rdar://problem/27879334 / SR-2351.
We had a few places that were performing ad hoc variants of
ConstraintSystem::getFixedTypeRecursive(); simplify it's interface so
we can use it everywhere consistently. Fixes rdar://problem/27261929.
If we found any error in a list, in most cases, we cannot expect that the
following tokens could construct a valid element. Skip them, instead of trying
to parse them as the next element. This significally reduces bogus diagnostics.
Bailout if seeing tok::eof or token that can never start a element, after
parsing an element. This silences superfluous "expected ',' separator" error,
or misleading expected declaration error. What we should emit is
"expected ')' in expression list, or "expected '}' in struct".
In most places where we were checking "is<ErrorType>()", we now mean
"any error occurred". The few exceptions are in associated type
inference, code completion, and expression diagnostics, where we might
still work with partial errors.
The idea here is that if a generic signature has invalid requirements,
we would drop all the requirements and build a new set of archetypes
without requirements.
When this logic was added, it fixed 700 compiler_crashers:
<c258f991f6>
Nowadays it appears that all the underlying issues were solved, so
removing this error path actually fixed two crashers and improved
a couple of diagnostics.
If '>' could not be found, the parser should return the location of the
last token parsed, instead of the current token.
Previously, it may causes ASTVerifier error "child source range not contained
within its parent" in some cases.
There's a bit of a hack to deal with generic typealiases, but
overall this makes things more logical.
This is the last big refactoring before we can allow constrained
extensions to make generic parameters concrete. All that remains
is a small set of changes to SIL type lowering, and retooling
some diagnostics in Sema.
The fixits call back into the type checker via typeCheckCheckedCast(),
which sets up a new constraint system. As a result we would hit
assertions by introducing type variables from a previous "generation".
It seems that if we bail out of this code path altogether, we get a
better diagnostic -- in the provided test, it complains about an
ambiguous member to '.value', rather than not being able to convert
_? to V?.
Fixes <https://bugs.swift.org/browse/SR-2592>.
