This introduces the notion of arenas into ASTContext, with two arenas
currently defined: one for 'permanent' storage, and another for the
current constraint checker. The latter is used when allocating any
types that involve type variables, which are only used temporarily
during type checking anyway.
This gives us a 1% speedup on swift.swift (because we're hitting
smaller hash tables when doing lookups) and < 1% memory reduction
(since that's not the main source of memory usage). It's more
important architecturally, so our memory usage doesn't grow with the
number of type-checks performed.
Note also that this arena scheme could be generalized, which we may
very well want to do in the future. For example, we could easily have
an arena for temporary nodes introduced by parsing (e.g.,
UnresolvedDeclRefExpr) or by name binding (OverloadedDeclRefExpr), and
clear that arena when we successfully move onto the next phase. Or, in
a REPL/debugger context, have a 'temporary' arena for
statements/expressions that can be removed.
Swift SVN r3175
rdar://11259972
Add a bit to LValueType representing NonSettable, and set it in the constraint-
based checker where a property or subscript expression resolves to a decl
without a setter or to a settable member of an unsettable value type. Tweak
constraint rules for subscript, address-of, assignment, and implicit byref
arguments to rule out operands that are not settable in a context that
requires settability, such as assignment or pass-by-reference.
Swift SVN r3136
rdar://10157547
This just adds the bit to Decl. Actually making use of it looks like it'll require some type checker work, which should probably wait till the new checker settles down. Also add some xfail tests of the sorts of cascading diagnostic errors we should be able to prune using invalid bits on decls.
Swift SVN r3099
rdar://12315571
Allow a function to be defined with this syntax:
func doThing(a:Thing) withItem(b:Item) -> Result { ... }
This allows the keyword names in the function type (in this case
`(_:Thing, withItem:Item) -> Result`) to differ from the names bound in the
function body (in this case `(a:Thing, b:Item) -> Result`, which allows
for Cocoa-style `verbingNoun` keyword idioms to be used without requiring
those keywords to also be used as awkward variable names. In addition
to modifying the parser, this patch extends the FuncExpr type by replacing
the former `getParamPatterns` accessor with separate `getArgParamPatterns`
and `getBodyParamPatterns`, which retrieve the argument name patterns and
body parameter binding patterns respectively.
Swift SVN r3098
We'll want a superclass pointer on ClassType and BoundGenericClassType,
and this also makes it easier to detect both kinds of class type.
Swift SVN r3061
conversions on metatypes; at runtime it has no effect,
since those conversions are always trivial. Fix a number
of bugs involving the conversion of metatypes, in both
typecheckers.
Swift SVN r3055
Introduce a '.metatype' form in the syntax and do some basic
type-checking that I probably haven't done right. Change
IR-generation for that and GetMetatypeExpr to use code that
actually honors the dynamic type of an expression.
Swift SVN r3053
Outside of a container, semicolons after decls are just parsed as SemiStmts.
Inside a container, though, we only allow decls...but we should still allow
trailing (delimiting?) semicolons.
If you have multiple semicolons in a row, though, that's probably a typo,
so parseDecl will now also complain (error) if it sees a semicolon where
a decl is expected.
<rdar://problem/12540877>
Swift SVN r3051
dispatch. Currently there is no possibility of override.
This was really not as difficult as I managed to make it
the first time through.
Swift SVN r2960
statements. The approach is fairly simple: generate constraints for
both the destination and source expressions, then turn the destination
type into a type containing only rvalues and convert the source
expression to that type.
Swift SVN r2925
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
rely at all on the existing type checker. Instead, just fold sequence
expressions (which are effectively a delayed parsing phase) and then
hand off the expression to the constraint solver.
Allows us to type-check expressions with operators, e.g., f + 1.
Swift SVN r2793
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
and type validation should never fail in a call to validateTypeSimple.
The one thing I really don't like about this whole approach is that we end
up with validateTypeSimple calls scattered all over the place...
the ultimate solution here is probably something along the lines of
introducing getUnvalidated() getters for types for use from the parser,
and make the standard getters for types assert that the type is valid
and perform any necessary computations themselves.
Swift SVN r2728
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
replace each archetype with a fresh type variable (that conforms to
the same protocols as the archetype) and make the resulting function
type monomorphic over those type variables. The resulting constraints
provide deduction for the generic parameters, e.g.,
swift> func ident<T>(x : T) -> T { return x }
swift> var x : Int
swift> :dump_constraints(ident(x))
---Constraints for the given expression---
(paren_expr type='T2'
(call_expr type='T2'
(declref_expr type='(x : T0) -> T0' decl=ident)
(paren_expr type='[byref(heap)] Int'
(declref_expr type='[byref(heap)] Int' decl=x))))
---Type Variables---
T0
T1
T2
---Constraints---
(x : T0) -> T0 == (T1) -> T2
[byref(heap)] Int << T1
Int = 0
Swift SVN r2632
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
