of protocol types to correctly handle self-assignment.
This ends up creating such a large amount of code that it's
worth extracting into its own helper function. Fortunately,
this can be the same helper function for every protocol type.
Swift SVN r1905
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
pointer TypeInfo more conveniently. Have this class return true for
isSingleRetainablePointer(). Further specialize the implementations
of the value witnesses so that we no longer ever require type-specific
witnesses for reference types.
Swift SVN r1900
value witnesses goes.
There are three major remaining things to do to support protocols:
- laying out the actual protocol members
- emitting witnesse for the actual protocol members
- detecting uses of the actual protocol members and funnelling
them through the witnesses as appropriate
All this work was just to let us treat protocol types as
first-class values.
Swift SVN r1899
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
allows access to any LLVM IR intrinsic that has types that can be mapped
to swift types. Notably, this excludes vector stuff, but there is a lot
of other goodness that can now be poked at.
Swift SVN r1890
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
level of IR struct type. At first we were emitting two layers
because structs were secretly tuples, and then more recently
we were emitting two layers to avoid having to adjust a bunch
of tests. Just bite the bullet now; it makes the IR a lot
cleaner, and it's never going to be easier.
Swift SVN r1824
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
It does seem silly for this to all be templated, but I couldn't
really see a very elegant solution given how I wanted things to
be genericized.
...interestingly, a ?t.t[] type would have done nicely for some
of this.
Swift SVN r1807
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
