Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
All of the malloc zone APIs are clumsy object-oriented design in C, but that
does not mean we should be too. This should clarify the design more too.
Swift SVN r15690
The ArrayType protocol is developed for NewArray is a good basis for
what we want, but the ability to create arrays without value semantics
is adding complexity but questionable value. It isn't clear that we can
usefully expose a type called SharedArray<T>, even internally, if it
ceases to be truly shared when one copy grows, and therefore has its
buffer reallocated. Therefore, leave the NewArray test with a
ArrayType2, a refinement of ArrayType, that adds the ability to report
on its value semantics.
If we really want the optimizations that can be had in a large-scale
mutation by first unique'ing the array and making mutations in-place
thereafter, we can fall back to operating on NativeArrayBuffer<T>
directly.
Swift SVN r15673
Good:
* We now no longer wrap the system malloc zone.
* Tiny allocation quantum is pointer sized, not 16 bytes.
* Far less metadata overhead than the system malloc zone.
Bad:
* Our heap density isn't quite as good as the default zone. This is a O(1)
versus O(N) tradeoff. The default malloc zone has been trending in this
direction too.
TODO:
* Introspection
* Tune secondary fast paths
* Huge allocations
Swift SVN r15269
Playgrounds want to be able to represent numbers different from strings, so provide different tags for types that represent numbers distinct from strings. Set up the Int and Double mirrors to return quick look objects of the appropriate cases, and hook up the magic ObjC mirror to do the same for NSNumbers. <rdar://problem/16360758>
Swift SVN r15219
Only the bits that actually need to grovel metadata really need to be written in C++, so define away hopefully most of the potential for memory safety or corruption bugs from screwing up calling convention matchups by moving most of the magic mirror implementations into pure Swift.
Swift SVN r15180
We'll need to apply the same tricks we're using for Array to Dictionary
and String, so prepare to generate base classes for those buffers as
well. Actually generate and use the one for Dictionary, but don't
actually bridge it yet.
Swift SVN r15167
We want the metadata of the ObjC class, not the opaque Builtin.ObjCPointer metadata. This allows the Any to actually be downcast to an expected type on the client side.
Swift SVN r15009
Now that we can read definitions directly from "C" headers, stop trying
to maintain a mirror of the HeapObject struct in Swift code in the
standard library.
Swift SVN r14982
Add 'Sound', 'Color', and 'BezierPath', as requested by Enrico, as well as a '_Raw' case that can be used for internal experimentation.
Swift SVN r14978
Turns out CMake's PRE_BUILD mode for custom commands doesn't work with the
Ninja or Makefile generators (not sure about Xcode). Just do it as part of
an earlier target instead.
Swift SVN r14968
