We will handle Swift-function-to-ObjC-block bridging in SILGen as part of general Cocoa-to-Swift type bridging. Temporarily disable building swiftAppKit and tests that exercise block bridging until the new implementation lands.
Swift SVN r5090
Most of this is mechanical, because we weren't actually relying on
byref(heap) for anything. Simplify capture analysis, now that the only
way a variable can have non-fixed lifetime is if it is actually
captured. Fixes <rdar://problem/11247831>.
Swift SVN r5046
During name binding, associate func decls with operator decls. When parsing SequenceExprs, look up operator decls to determine associativity and precedence of infix operators. Remove the infix_left and infix_left attributes, and make the infix attribute a simple declared attribute [infix] with no precedence.
Operator decls are resolved as follows:
- If an operator is declared in the same module as the use, resolve to the declaration in the current module.
- Otherwise, import operator declarations from all imported modules. If more than one declaration is imported for the operator and they conflict, raise an ambiguity error. If they are equivalent, pick one arbitrarily.
This allows operator declarations within the current module to override imported declarations if desired or to disambiguate conflicting operator declarations.
I've updated the standard library and the tests. stdlib2 and some of the examples still need to be updated.
Swift SVN r4629
By splitting out the expression used to allocate 'this' (which exists
in the AST but cannot be written in the Swift language proper), we
make it possible to emit non-allocating constructors for imported
Objective-C classes, which are the only classes that have an
allocate-this expression.
Swift SVN r3558
Currently only used for parsing. The immediate intent of these attributes is
to have them behave like [objc] for the purpose of emitting method
implementations; however, they are semantically distinct and should only be
used to expose outlets and actions to Interface Builder.
Swift SVN r3416
This implementation is very lame, because we don't currently have a
way to detect (in Sema or SIL) where 'this' gets uniquely assigned,
and turn that assignment into initialization.
Also, I'm starting to hate the name 'allocating' constructor, because
it's the opposite of the Itanium C++'s notion of the allocating
constructor. Will think up a better name.
Swift SVN r3347
A user-defined conversion function is an instance method that accepts
an empty tuple and returns a value of the type we're converting to,
has the [conversion] attribute, and is named __conversion. The last of
these restrictions is a temporary hack to work around our inability to
perform a lookup across all extensions for "every function with the
conversion attribute", and shouldn't last too long.
As in C++, we only get one user-defined conversion function. Unlike in
C++, a constructor is not (and cannot) be a conversion function.
Introduce NSString <-> String conversion functions, but leave the
runtime implementations as stubs for Dave to fill in.
Swift SVN r1921
applies to operators whose first parameter is [byref]. Assignments
must return Void, and have their first arguments implicitly treated as
an lvalue.
As part of this, add the various C compound operators (+=, -=, *=, /=,
&=, |=, and ^=) to the standard library.
Swift SVN r1846
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
- 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
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
