application expressions that provide a 'this' parameter to a
method. There will eventually be more than just DotSyntaxCallExpr, to
capture the other syntactic (and implicit) forms.
Swift SVN r1924
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
wrap it in an 'id' type in the standard library.
Also fix a bug noticed by inspection where initWithTake for
function types wasn't entering a cleanup for the taken value.
This probably doesn't matter for existing possibilities, but
it's potentially important under exceptions.
Swift SVN r1902
This is <rdar://problem/10217868>. Apparently I'm using Lion's
libc++ headers somehow, which I should probably fix; but since
the use of shared_ptr is just a hack until DenseMap supports
move-only types, I don't feel bad about changing it to a different
hack that avoids shared_map altogether.
Swift SVN r1897
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
another function type, so long as the source is a subtype of the
target. The subtyping relation is fairly obvious, allowing parameter
renaming, qualification conversions for lvalue types, and
protocol-conformance conversions (at the top level of function
types). It is a strict subset of the allowed type coercions.
The representation of FunctionConversionExpr is temporary. It will
need to account for the capture of the source of the conversion in the
trivial-trivial case.
Swift SVN r1839
in general, not sound. For the limited cases where we did use this
expression kind on lvalues (member access or instance method
invocations on a superprotocol), leave the conversion to the client of
their respective AST nodes (MemberRefExpr, DotSyntaxCallExpr). We may
decide to enrich these ASTs in the future with more information about
the conversion path, but it's not clear that it's actually useful
information for, e.g., IRgen.
Swift SVN r1830
[byref(implicit)], and rely on type coercion for the implicit object
argument to deal with the implicitness. This is one half of
<rdar://problem/11215969>.
The other half of <rdar://problem/11215969> requires us to invent some
syntax to allow increment/decrement/assignment to operate on lvalues
without requiring one to write '&'. There are two distinct ideas
gaining traction here:
- Adding an [assignment] attribute to these operators, which tells
us both that use of the operators is a statement (not an
expression) and that the byref argument (either on the left, or
the only argument).
- Allowing operators to be written as member functions, so that they
get the same treatment as "a.b".
The former seems like the better option.
Swift SVN r1819
from a protocol to a protocol it inherits. This is a far simpler
operation that the general type-erasure expression, so generate this
AST when we can.
Swift SVN r1813
conversion for the implicit argument of a method ('this'), along with
an entry point (coerceObjectArgument) to perform type coercion of the
object argument to an lvalue. Use this entry point for member
reference expressions (that refer to variables/properties) and method
calls. This is a step toward eliminating [byref(implicit)] on the
implicit 'this' parameter.
More immediately, use this to close up the giant type-safety loophole
I introduced yesterday regarding conversions to references of protocol
type.
Swift SVN r1812
protocol Document { var title : String }
protocol Versioning { func bumpVersion() }
protocol VersionedDocument : Document, Versioning { }
This commit covers the basic functionality of protocol inheritance, including:
- Parsing & AST representation
- Conforming to a protocol also requires conforming to its inherited
protocols
- Member lookup into a protocol also looks into its inherited
protocols (results are aggregated; there is no name hiding)
- Teach ErasureExpr to maintain lvalueness, so we don't end up
performing a silly load/erase/materialize dance when accessing
members from an inherited protocol.
Swift SVN r1804
