that are not handled by a visitor. Make their implementation chain up to a parent node's
implementation. For example, a (silly) visitor could choose to just implement visitExpr
and get all nodes.
Swift SVN r1194
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
When we divide the world into scripts and modules, this
won't matter for the former. Recognize <stdin> as a
special case; it should instead just always be a script.
Fixes rdar://problem/10986311.
Swift SVN r1181
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
- introduce the concept of qualifiers on l-value types
- teach overload resolution and coercion how to drop explicitness
- require explicitness on normal [byref] arguments
- make 'this' [byref(implicit)]
- special-case '&' as a unary operator in the parser to make it
produce an expression which type-checks as turning implicit l-values
into explicit ones.
Obvious missing pieces:
- updating LangRef
- we should really complain about ever trying to rvalue-convert an
explicit l-value
- maybe qualification should play a part in overload resolution
- we should diagnose attempts to declare unary '&' operators
- there's a test case in expressions.swift which suggests my logic is
slightly off
But I am out of time, and these will have to wait.
Swift SVN r1119
not have reference semantics. Deciding whether the container
type has reference semantics requires us to perform
some amount of limited name-binding and type-checking first,
which introduces a few complexities.
Also, fix a bug in uncurried call emission.
Methods work now.
Swift SVN r1112
it doesn't appear in places it shouldn't. The only limits on
this checking right now is the inadequacy of location information
for types, which is something we ought to fix.
Fix type-checking of byref applications. Fix IR generation
of byref variables. Whole lotta fixin' goin' on.
But hey, byref calls work.
Swift SVN r1111
except 'func'. It doesn't make any sense to me for operators
to have variable semantics, and it's unnecessary complexity
in the type-checker.
Swift SVN r1108
instead .
1,2d
1i
Change the 'walk' APIs to use virtual dispatch instead of
blocks. This makes it much easier to thread information
through the API, as well to extend the API to handle
recursive visiting of other structures (e.g., Decls
and Patterns).
Swift SVN r1101
A function argument clause is now one or more patterns (which
must be parenthesized and explicitly type all positions) not
separated by arrows; the first arrow then separates off the
return type.
Revisions to language reference forthcoming.
Swift SVN r1099
