It might be possible to save some memory by breaking the AnonClosureArgExpr linked list during type-checking... not sure if that's worthwhile.
Swift SVN r1248
qualifier, making sure that variables end up so-qualified by
default. Add a RequalifyExpr to capture the act of adding
qualifiers (to form a supertype) to an l-value.
Swift SVN r1236
Teach Expr::getSemanticsProvidingExpr to look through DotSyntaxBaseIgnoredExpr.
Start generating DotSyntaxBaseIgnoredExpr for all dot syntax exprs where the base is
ignored (e.g. "Builtin.mul_i32"), which preserves a lot more source location information
and is general goodness for the AST.
Swift SVN r1232
to properly represent its newly generalized role. It is formed
for things like "swift.print" where swift is a module type and is
evaluated and ignored.
Swift SVN r1230
inform conversion ranking about auto_closure, and rip out the
CR_AutoClosure implicit conversion. Our conversion ranking is
now completely trivial: we either have an identity conversion
or an invalid one - no crazy implicit conversions (still have
tuple shuffles etc though).
Swift SVN r1192
in favor of a single-element non-canonical TupleType) broke the type
system, in that supposed sugar (the TupleType) supported a different
set of operations from the canonical type. For example, a
single-element unlabelled tuple type supports elementwise projection
(foo.$0), but the underlying element does not (or supports it
differently).
The IR-gen failure was due to a very related problem: IR-gen
was not updated to reflect that a single unlabelled tuple element
is the same type as its element type, and therefore it was giving
different representations to these types ({ %foo } and %foo,
respectively), which broke widespread assumptions.
The removal of ParenType was done in pursuit of an AST invariant
that's not actually particularly interesting in the first place
and which, furthermore, is problematic to attain.
Swift SVN r1182
empty tuple as an argument. This should be restricted even more (rdar://10983400)
but this eliminates the most surprising cases at least.
Swift SVN r1165
example:
t.swift:2:39: error: invalid conversion from type 'double' to 'int'
var closure5 : (double) -> int = { $0 + 1.0 }
~~~^~~~~
t.swift:2:34: note: while converting closure body to inferred return type 'int'
var closure5 : (double) -> int = { $0 + 1.0 }
^ ~~~~~~~~
t.swift:2:1: note: while converting 'var' initializer to declared type '(double) -> int'
var closure5 : (double) -> int = { $0 + 1.0 }
^
Swift SVN r1158
struct point { x : int, y : int }
var (a, b) = foo() // when foo returns a 'point'
allowing this breaks our fragility model (e.g. members can be added/removed from the struct) and this generally needs to be integrated with our pattern matching stuff. rdar://10934540
Swift SVN r1135
