Rely on opening the GenericFunctionType of a method, rather than its
PolymorphicFunctionType. Alas, constraint application still falls back to
the PolymorphicFunctionType.
Swift SVN r9564
Replace DeclRefExpr's stored ValueDecl* with a ConcreteDeclRef,
allowing it to store the complete set of substitutions applied to
the declaration. Start storing those substitutions (without using them
yet).
Swift SVN r9535
This variant of specialize() uses the requirements list of the generic
function type to form the substitution list, rather than relying on
the polymorphic function type and all-archetypes lists.
Swift SVN r9518
When the type checker sees a reference to a generic non-member
function, open its interface type, which is expressed as a
GenericFunctionType, rather than its PolymorphicFunctionType. This is
a tiny step toward weaning the type checker off archetypes within the
interface.
Swift SVN r9504
Fix TypeChecker::isSubtypeOf() to actually solve the created system,
and introduce TypeChecker::isTrivialSubtypeOf() to handle the check
for trivial subtyping.
Swift SVN r9385
The constraint solver was eagerly applying the T -> U? conversion
rule, which only succeeds when T is convertible to U. Thus, we would
reject valid code where T has a user-defined conversion to
U?. Instead, introduce a disjunction conversion to try either T -> U?
by converting T to U or via a user-defined conversion.
Most of this is infrastructure for the introduction of constraint
restrictions, which specify that a particular constraint (say, a
conversion constraint) should only try a single direct path:
scalar-to-tuple, value-to-optional, user-defined, etc. Each term in the
disjunction created for the T -> U? case is restricted to a particular
conversion rule, so that checking it does not create another
disjunction.
Keep track of the constraint restrictions we used within a given
solution, so that we can replay those steps during the application
phase. There is a bunch of inactive code here at the moment, which
will become useful as we start creating disjunctions for other
ambiguous conversions.
Swift SVN r9318
ConstraintSystem::matchTypes() currently believes that there is only
one way in which two types might match each other. That being patently
untrue, start capturing the set of conversions that could potentially
work, so that we can turn them into disjunctions if when.
No functionality change yet; this is just refactoring.
Swift SVN r9227
Overload bindings constraints bind a given type to a specific overload
choice. This is a step toward moving overload sets into normal
disjunction constraints.
Part of the work here is to eliminate the constraint system's
dependence on OverloadSet, which will be going away in favor of a
disjunction constraint.
Swift SVN r9209
This introduces "class" constraints into the type checker, so that we
can specify that a particular type must be a class (or an archetype
that is required to be a class). Finishes <rdar://problem/15139128>.
Swift SVN r9176
Require that either T be default constructible or that the user provide a closure that maps indices to initial values. We don't actually call the closure yet to initialize the array; that's blocked on function abstraction difference <rdar://problem/13251236>.
Swift SVN r8801
AST used to depend on Sema in type printing. Specifically,
TypeVariableType::printImpl() is inside Sema.
This change moves the type variable identifier from
TypeVariableType::Implementation to TypeVariableType. This enables us to print
type variables in AST library.
Because type variable type is a temporary type for use inside type checker
only, I don't expect that we will modify it to be more verbose to enhance
diagnostics. This is a job for locator printing.
Swift SVN r8559
system.
Tweak the tuple conversion rule so that labeled elements can lose
their label (but not change it or get passed as a vararg) if the
label wasn't written immediately in a tuple literal. This permits
var (a,b) = fn_returning_labeled_tuple()
to successfully type-check, as well as the analogous assignment.
This implies an unfortunate number of test changes, including some
QoI regressions, which I tried to limit as much as I could.
Swift SVN r8438
The new ConcreteDeclRef class provides a possibly-speciaized reference
to a declaration, which allows DynamicMemberRefExpr to refer to both
generic and non-generic members. without having to split the AST node.
Swift SVN r7839
When performing member lookup into an existential that involves the
DynamicLookup protocol, look into all classes and protocols for that
member. References to anything found via this lookup mechanism are
returned as instances of Optional.
This introduces the basic lookup mechanics into the type
checker. There are still numerous issues to work through:
- Subscripting isn't supported yet
- There's no SILGen or IRGen support
- The ASTs probably aren't good enough for the above anyway
- References to generics will be broken
- Ambiguity resolution or non-resolution
Thanks to Jordan for the patch wiring up DynamicLookup.
Swift SVN r7689
The type checker has a poor habit of inferring lvalue types where it
shouldn't, or (more rarely) dropping lvalue types when it should keep
them. Only allow a type variable to bind to an lvalue type in specific
situations where it makes sense (e.g., the type variable represents an
overload set that may contain a variable). Fixes <rdar://problem/13827562>.
Swift SVN r7179
Normal type lookup would find and substitute deduced associated types
appropriately, but the constraint solver's handling of member
references failed to account for them. Make sure we handle them now,
fixing <rdar://problem/14638725>.
The bulk of this change actually fixes the type vs. value member
confusion within the solver. Previously, our notion of an overload
choice lost track of whether we were looking for a type vs. a
value. This meant that we would end up getting metatypes when in fact
we expected types, and we had a few workarounds in the solver and in
the protocol conformance checker to work around that bug. Track that
we're looking for a type in OverloadChoice, so we can propagate that
information. Consequently, eliminate all of the hackarounds involving
metatypes that shouldn't be metatypes.
Swift SVN r7009
When we're diagnosing an error during the initialization of a
parameter from an argument, point at the actual parameter (if we can
find it) or at least the function (if we can't) where the call
failed. Baby steps:
t2.swift:3:4: error: '(x : Int, y : Int)' is not a subtype of 'Int'
f3(f3b)
^
t2.swift:1:9: note: in initialization of parameter 'x'
func f3(x : (x : Int, y : Int) -> ()) {}
^
Swift SVN r6924
Rather than maintain a big DenseMap that was only ever used for
iteration, use a constraint-system--allocated linked list with a
shared head. Good for 1.5% compile time on the standard library, and a
necessary refactor for tracking more information for diagnostics.
Swift SVN r6907
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
