doesn't die if the same witness is required on multiple lines.
The right solution here is to find some way to re-use the
previous functions.
Swift SVN r1994
match the actual entrypoints vended by the runtime:
1) there is no swift_slowRawAlloc
2) swift_deallocObject takes two arguments
Also, make all calls to swift_allocObject go through a common
function so that we can easily use optimized entrypoints if the
runtime provides them.
Swift SVN r1993
values of existential type, e.g.,
var x : Printable
x.print()
Existential member references reify the type of the implicit object
argument (implicitly, because we have no way of expressing this in the
type system), and replace the types of any other archetypes
with existential types that (don't, but will eventually) conform to
the protocols to which the archetypes conform.
Swift SVN r1963
using the term "unresolved" in expressions for a while, and it fits
for types better than "dependent type."
The term "dependent type" will likely come back at some point to mean
"involves an archetype".
Swift SVN r1962
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
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
