Finishes off <rdar://problem/12337042>.
Also, fix constraint application so that test/Constraints/closures.swift
doesn't explode with the above fix.
Swift SVN r2888
since we're now applying solved constraints to an expression to
produce a well-typed expression. The resulting expressions are now
returned and run through the verifier, so deal with some of the
byref(implicit) fallout.
Swift SVN r2835
constraint-based type checker. We now model the address-of operator
with the constraint
[byref] T1 < T2
where T1 is a fresh variable and T2 is the type of the subexpression
of &.
Note that there's a little hack in the constraint generator that
strips off the 'heap' qualifier when performing constraint-based type
checking, because we're not actually using it for overloading (merely
as an aid for IRgen) and it causes some trouble in the modeling of the
address-of operator.
We can now properly reject code such as
swap(a, b)
which should be
swap(&a, &b)
Swift SVN r2797
conversions. We limit the relationship between the result of the
conversion and the actual expected type to a subtyping relationship,
which effectively limits us to applying a single user-defined
conversion function (rather than a chain of such conversions).
Later, we can consider extending this to a chain of conversion
functions, but that will require us to cope with cyclic conversions
and minimizing conversion sequences (e.g., if A -> B -> C and A -> C
are both possible, we should prefer A -> C).
Swift SVN r2730
is really a deficiency in TypeInfo::initializeWithTake, which
is now virtual and not implemented in TypeInfo anymore. This
fixes rdar://problem/12153619.
While I'm at it, fix an inefficiency in how we were handling
ignored results of generic calls, and add 4 new builtins:
Builtin.strideof is like sizeof, but guarantees that it
returns a multiple of the alignment (i.e., like C sizeof,
it is the appropriate allocation size for members of an
array).
Builtin.destroy destroys something "in place"; previously
this was being simulated by moving and ignoring the result.
Builtin.allocRaw allocates raw, uninitialized memory, given
a size and alignment.
Builtin.deallocRaw deallocates a pointer allocated with
Builtin.allocRaw; it must be given the allocated size.
Swift SVN r2720
a reliable way to track whether a particular type has been
validated. Instead, add some bits to the type to indicate which stage
of checking it has received. I hate it, but it works and I don't know
of a better way to ensure that types get validated. This subsystem
will need to get rearchitected at some point (ugh).
Reduce the number of places where we build new BoundGenericTypes,
since they need to be validated fully to get substitutions, and then
introduces a number of validateTypeSimple() calls to validate types in
places where we know the validation will succeed, but we need that
information regardless.
Swift SVN r2681
generation from an expression that has not been type-checked. One can
see the constraints introduced by an expression by using
:dump_constraints <expression>
within the REPL. We're still missing several major pieces of
constraint generation:
- We don't yet "open up" references to polymorphic types
- We don't print out the child constraint systems in the dump, so
it's not at all obvious what happens within overloading (and I'm not
convinced I like my representation anyway)
- There are no tests whatsoever
- Member constraints are still very, very weird
Swift SVN r2624
static method to call it, to make it more explicit what is happening. Avoid
using TypeLoc::withoutLoc for function definitions; instead, just use an empty
TypeLoc.
Swift SVN r2606
Builtin.ObjectPointer, and Builtin.RawPointer. I don't really like the way
these builtins are defined (specifically, the part where messing up
gives a mysterious IRGen error), but it's workable. <rdar://problem/11976323>.
Swift SVN r2585
parameters we're substituting. This is either "all levels" (when we're
substituting a specific base type in a member access) or "the
innermost level" (when we're substituting after deducing from a use or
application of a polymorphic function).
Swift SVN r2576
checker. There are a few related sets of changes here:
- Generic parameter lists have a link to their "outer" generic
parameter lists, so its easy to establish the full generic context
of an entity.
- Bound and unbound generic types now carry a parent type, so that
we distinguish between, e.g., X<Int>.Inner<Int> and
X<Double>.Inner<Int>. Deduction, substitution, canonicalization,
etc. cope with the parent type.
- Opening of polymorphic types now handles multiple levels of
generic parameters when needed (e.g., when we're substituting into
the base).
Note that the generics module implied by this representation restricts
what one can do with requirements clauses in nested generics. For
example, one cannot add requirements to outer generic parameters or
their associated types, e.g., this is ill-formed:
struct X<T : Range> {
func f<U requires T.Element : Range>() {}
}
The restriction has some precedent (e.g., in C#), but could be
loosened by rearchitecting how we handle archetypes in nested
generics. The current approach is more straightforward.
Swift SVN r2568
types in a few ways:
- Actually check the extra requirements placed on associated types,
e.g., "T.Element : Ordered"
- Actually encode/store the protocol conformance information for a
BoundGenericType in the same way that we do for SpecializeExpr,
GenericMemberRefExpr, and GenericSubscriptExpr. Yay, consistency.
- Move the storage for the protocol conformance information into a
DenseMap in the ASTContext indexed by canonical BoundGenericType, so
it doesn't require inline storage in BoundGenericType.
Swift SVN r2517
member of a oneof/struct/class/extension to support types nested
within generic classes, e.g., Vector<Int>.ElementRange.
Most importantly, nominal types are no longer inherently canonical. A
nominal type refers to both a particular nominal type declaration as
well as its parent, which may be non-canonical and will vary. For
example, the variance in the parent makes Vector<Int>.ElementRange and
Vector<Float>.ElementRange different types.
Introduce deduction and substitution for nominal types. Deduction is
particular interesting because we actually do allow deduction of T
when comparing X<T>.Inner and X<Int>.Inner, because (unlike C++) there
is no specialization to thwart us.
Swift SVN r2507
polymorphic type when that type is nested within a generic type. The
type-checker still isn't ready to use these declarations in a sane way.
Swift SVN r2501
This is much more convenient for IRGen, and gives us a reasonable representation for a static
polymorphic function on a polymorphic type.
I had to hack up irgen::emitArrayInjectionCall a bit to make the rest of this patch work; John, please
revert those bits once emitCallee is fixed.
Swift SVN r2488
have a record of how the member is being specialized for the given
context. To do this, I also had to patch up the DeclContext for
template parameters.
Swift SVN r2483
type. This has remarkably little effect on type checking, because the
destructors themselves are never referenced by the AST after initially
type-checking them.
Swift SVN r2474
including the weird implicit one-of element declarations that end up in struct
types. Teach overload resolution and the type-checking of
ConstructorRefExprs how to specialize these polymorphic function types.
Swift SVN r2473
polymorphic function type. For example, given
struct X<T> {
func f(a : T) -> Int { }
}
The type of X.f is
<T> (this : [byref] X<T>) -> (a : T) -> Int
If we have a call to f, e.g.,
var xi : X<Int>
xi.f(5)
it will be represented as X.f specialized to type
(this : [byref] X<Int>) -> (a : Int) -> Int
and then called with 'xi' (DotSyntaxCallExpr) and finally 5
(ApplyExpr). The actual deduction of arguments is not as clean as I'd
like, generic functions of generic classes are unsupported, static
functions are broken, and constructors/destructors are broken. Fixes
for those cases will follow.
Swift SVN r2470
in SpecializeExpr, so that we have complete substitution and
protocol-conformance information. On the IR generation side, pass
witness tables for all of the archetypes (again, including derived
archetypes) into generic functions, so that we have witness tables for
all of the associated types.
There are at least two major issues:
(1) This is a terribly inefficient way to pass witness tables for
associated types. The witness tables for associated types should be
accessible via the witness tables of their parent. However, we need
more information in the ASTs here, because there may be additional
witness tables that will need to be passed for requirements that are
placed on the associated type by the generic function itself.
(2) Something about my test triggers a void/non-void verification failure
in the witness build for an instance function whose abstracted form
returns an associated type archetype and whose concrete form returns
an empty struct. See the FIXME in the test.
Swift SVN r2464
and derived) so they can be stored within the generic parameter list
for use 'later'.
More immediately, when we deduce arguments for a polymorphic function
type, check that all of the derived archetypes conform to all of the
protocol requirements, stashing that protocol-conformance information
in the coercion context (also for use 'later'). From a type-checking
perspective, we now actually verify requirements on associated types
such as the requirement on R.Element in, e.g.,
func minElement<R : Range requires R.Element : Ordered>(range : R)
-> R.Element
Swift SVN r2460
