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
A SuperRefExpr semantically includes an upcast, and coercing it to a deeper subclass by wrapping it in a DerivedToBaseExpr is redundant and confuses SILGen. Instead, update the type of the SuperRefExpr directly before loading from it. Fixes <rdar://problem/14581294>.
Swift SVN r6720
Add the new ApplicableFunction constraint to represent loose function
type equality - one type is applicable to another, if their inputs
and outputs match. I've removed the hack on [auto_closure], so
type checking a call to a function with attributes
("auto_closure" or "noreturn") is handled in the same way now.
Disables a test case (added in r6598) that was relying on the previous
behavior. Doug has offered to fix it.
Swift SVN r6629
We were inferring the locator from an already-rewritten expression,
which resulted in a completely useless locator. Use the correct
(pre-rewrite) locator. Also, eliminate the Solution::coerceToType()
overload that infers the locator, since it was inferred the wrong
thing in two out of the three callers. Fixes <rdar://problem/14429520>.
Swift SVN r6448
When we form a tuple that uses default arguments, find the source of
the default arguments (which will be a function or constructor
declaration). This information will eventually be introduced into the
AST.
Swift SVN r6277
Introduces very basic support for diagnosing ambiguous expressions,
where the source of the ambiguity is a reference to an overloaded
name. Simple example:
t.swift:4:1: error: ambiguous use of 'f0'
f0(1, 2)
^
t.swift:1:6: note: found this candidate
func f0(i : Int, d : Double) {}
^
t.swift:2:6: note: found this candidate
func f0(d : Double, i : Int) {}
^
There's a lot of work needed to make this cleaner, but perhaps it will
ease the pain of developing the library <rdar://problem/14277889>.
Swift SVN r6195
When checking a type's conformance against a protocol, we can deduce
the values of associated types. Make these associated types visible to
qualified name lookup so that (for example) VectorEnumeratorType does
not need to define the Element type. It is deduced from the signautre
of next(), and made available as, e.g.,
VectorEnumeratorType<Int>.Element through the Enumerator protocol
conformance. Fixes <rdar://problem/11510701>, but with some lingering
dependencies on lazy type resolution (<rdar://problem/12202655>).
Note that the infrastructure here is meant to be generalized to
support default implementations in protocols, but there are several
pieces still not in place.
Swift SVN r6073
