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
When the name of a generic type is referenced, without any generic
arguments, within the definition of a generic type (or extensions of
that generic type), use the generic arguments provided by that
context. Thus, within the definition of X<T> below, one can simply use
'X' as a shorthand for 'X<T>':
class X<T> {
func swap(other : X) { /* ... */ } // same as "func swap(other : X<T>)"
}
This resolution provides essentially the same behavior as the
injected class name does in C++. Note that this rule overrides any
inference rules, such that (for example) the following is ill-formed
rather than inferring the generic arguments of 'X':
class X<T> {
func foo() {
var xi : X<Int> = X()
}
}
Note that name binding has changed slightly: when unqualified lookup
finds a type declaration within a nominal type, it is now treated as
a DeclRefExpr (or overloaded variant thereof) rather than as a member
access with an implicit 'this'.
Fixes <rdar://problem/14078437>.
Swift SVN r6049
The new TypeChecker::lookupMemberType() handles substitution of the
base type into the type result, as well as eliminating results for
which the resulting types are equivalent.
Swift SVN r5927
When we coerce an ExprPattern, set up a constraint system to check the leaf expression using overload resolution on the ~= operator. Save a specialized DeclRef to the overload we find in the ExprPattern for later codegen.
Swift SVN r5920
A type variable can be fully bound by either an overload set (when
selecting an overload will provide a binding for the type variable) or
by a member constraint (when the base type is determined, the member
type will be known). This keeps the solver from making really, really
bad type variable bindings based on context information.
Swift SVN r5634
Move this computation into the "fixed" part of the scoring, because it
is not actually relative. Collapses the linear-time check down to a
constant-time check based on the locator.
Also, unify the constraint generation logic for all of the basic type
literals (integer, float, character, string) now that we have a common
mapping from expression to literal protocol.
Swift SVN r5590
Use this N-way solution "diff" when comparing two solutions to
determine which is better. No actual functionality change here,
because we're still not comparing overload choices.
Swift SVN r5518
Set up constraints for AssignExprs within the constraint system instead of using typeCheckAssignment to set up their own isolated system. Kill the goofy hack not to consider a single-AssignExpr closure to be single-expression-body, because single-assign-expr-body closures now type-check successfully.
typeCheckAssignment still lingers because of a couple uses in typeCheckConstructorBody, but those should be easy to kill off next.
Swift SVN r5504
This eliminates the last of the old "convert literal to specific type"
code, as all of the basic literal kinds now go directly through formal
protocols. One minor casualty of this change is that we've lost the
"integer constant too large" warning. Filed as
<rdar://problem/14070127>, which is likely to be addressed in SIL.
Swift SVN r5477
Thread the current DeclContext down into expression type-checking so that we will be able to set up ImplicitClosureExprs with the right parent context. (Don't actually set the right decl context when creating an ImplicitClosureExpr yet, since IRGen isn't quite ready to handle specialized partial applications and crashes on the emitted SIL if we do.)
Swift SVN r5431
Add a version of TypeChecker::typeCheckExpression() that performs a
"shallow" type-check of just the top-level expression, rather than a
"deep" type-check of the full expression. Use it to eliminate
TypeChecker::semaApplyExpr().
Swift SVN r5394
We were generating constraints from a slightly different expression
than we were applying the constraints to, which could produce odd
crashes. Be more principled about using the modified expression.
Swift SVN r5384
If we fail to find a solution, solve the system again and track the
remaining failures. Provides a 13% improvement in the time to parse
swift.swift.
Swift SVN r5344
The former should always be recorded, because they are always
reported, and require far less effort to report. The latter can be
lazily computed (only when we found no solution and no unavoidable
failures) and will require far more work to diagnose. No functionality
change.
Swift SVN r5340
This eliminates tracking of type variable bindings we've made during
initial constraint generation, where we wouldn't ever undo those
changes anyway.
Swift SVN r5337
When we're trying to convert one tuple to another, and we hit a
problem that doesn't require us to actually perform more type
comparisons (mismatched labels, not enough elements, etc.), fall back
to attempt a scalar-to-tuple conversion when the target tuple can be
initialized by a scalar.
This is *not* a complete solution to this problem. It handles the
obvious cases, but for the non-obvious cases we'll have to pursue both
paths separately to see which one pans out.
Nonetheless, this fixes most of <rdar://problem/11293232>, as well as
<rdar://problem/13820721> and <rdar://problem/13394261>.
Swift SVN r5295
