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
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
