Update CSGen/CSApply/CSSolver to primarily use getType() from
ConstraintSystem.
Currently getType() just returns the type on the expression. As with
setType(), which continues to set the type on the expression, this
will be updated once all the other changes are in place.
This change also moves coerceToRValue from TypeChecker to
CosntraintSystem so that it can access the expression type map in the
constraint system.
I've been unable to reproduce the issue that hit on the builder, and
still expect this change to be NFC, so trying it out again. If it
fails, I'll revert again and try another shot at reproducing.
Original commit message:
We create new expressions that have the type on the expression
set. Make sure we capture these types in the constraint system type
map so that we can refer to types uniformally by consulting the map.
NFC.
(cherry picked from commit 57d5d974ff)
We create new expressions that have the type on the expression
set. Make sure we capture these types in the constraint system type
map so that we can refer to types uniformally by consulting the map.
NFC.
The setType() function in ConstraintSystem still sets the types on the
expressions themselves and that will continue until everything is
moved over to using the map.
Unfortunately this exposed cases where we are currently setting the
type multiple times to different values, so I've commented out the
assert that I previously added. I will circle back and start looking
into those issues once everything is moved over.
NFC for now.
In FailureDiagnosis::visitApplyExpr and CalleeCandidateInfo try to look
through ImplicitlyUnwrappedOptional function type, which improves diagnostics
for calls with invalid arguments.
Resolves: SR-3248.
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.
- In functions called from resolveType(), consistently
use a Type() return value to indicate 'unsatisfied
dependency', and ErrorType to indicate failure.
- Plumb the unsatisfiedDependency callback through the
resolution of the arguments of BoundGenericTypes, and
also pass down the options.
- Before doing a conformance check on the argument of a
BoundGenericType, kick off a TypeCheckSuperclass request
if the type in question is a class. This ensures we don't
recurse through NominalTypeDecl::prepareConformanceTable(),
which wants to see a class with a valid superclass.
- The ResolveTypeOfDecl request was assuming that
the request was satisfied after calling validateDecl().
This is not the case when the ITC is invoked from a
recursive call to validateDecl(), hack this up by returning
*true* from isResolveTypeDeclSatisfied(); otherwise we
assert in satisfy(), and we can't make forward progress
in this case anyway.
- Fix a bug in cycle breaking; it seems if we don't invoke
the cycle break callback on all pending requests, we end
up looping forever in an outer call to satisfy().
- Remove unused TR_GlobalTypeAlias option.
This map will be used instead of directly accessing types on
expressions. This will allow us to avoid mutating the types on
expression trees directly, making it possible to remove code that
currently attempts to save & restore types, and reducing the number of
bugs that exist as a result of not always perfectly saving & restoring
types (e.g. dangling references to released type variables).
The setType() function introduced here currently still sets the type
on the expression, so this change is NFC. This is just step one of
staging in this transition to using the types from the maps.
A map for TypeLocs and possibly other maps for other types we mutate
will be added in future commits.
While not strictly needed for type checking, it's extremely useful for
debugging and verification to know what context a particular generic
environment is associated with. This information was in a kludgy side
table, but it's worth a pointer in GenericEnvironment to always have
it available.
We no longer need a separate "pass" that creates an archetype builder
that inherits context archetypes, because we no longer ever inherit
context archetypes.
When called with a ParenType wrapping a DependentMemberType,
we would drop the ParenType because we used type->getAs<ParenType>()
rather than dyn_cast<ParenType>(type.getPointer()).
This fixes an existing QoI issue with closure argument tuples,
and prevents another regression once SubstitutedType is removed.
This is a hack to avoid crashing on invalid code where a protocol is
nested inside some other generic context, and one attempts to use a
generic parameter or associated type from the enclosing generic
context. Any attempts to do so will violate the invariant that
protocols are top-level, which now crashes much more readily.
@slava_pestov is working on a far more principled fix for this area.
Prior to this change, nested generics always reused the archetypes of
either enclosing contexts. For example, given:
struct X<T> {
func f<U>(_: U) { }
}
The generic environment for X.f(_:) would use the same archetype for T
as the generic environment X. This reuse allowed some sloppiness
within the implementation---one did not necessarily have to remember
to substitute entities that came from an immediate outer context---but
caused an annoying limitation that nested generics could not add any
constraints to an archetype that came from an outer scope. Worse, the
compiler would not always diagnose this as an error, leading to
constraints being silently dropped, as in the example from the
referenced radar (see the change to
test/Generics/associated_types.swift).
Now, build a fresh generic environment for each context that
introduces new generic parameters, with archetypes that are completely
separate from the archetypes of enclosing contexts.
Fixes rdar://problem/29207581.
When referring to a declaration from an enclosing scope, make sure to
map the contextual type from its declaring context to the context from
which the declaration is referenced.
This routine was passing a 'null' generic environment when it should,
in fact, provide the generic environment for its context. Fixes a
code-completion regression introduced by the removal of
PartialGenericTypeToArchetypeResolver.
The GenericTypeOrArchetypeResolver changes are effectively porting
some existing hacks from the now-dead
PartialGenericTypeOrArchetypeResolver, which dodges some regressions
in the compiler-crashers suite and fixes 11 new crashers. There is
undoubtedly a more principled approach to fix these problems, most of
which now step from recursively looking for a generic environment that
isn't there, but doing so requires improvements to our name lookup.
