Metatype metadata now always refers to the maximally-abstracted @thick metatype representation, so metatypes are never trivial from the runtime's point of view.
Swift SVN r21975
constructs generic class metadata properly when the
superclass has an unexpected prefix.
Also fix a bug in the constructor for ClassMetadata (which is
only actually constructed this way in unit tests).
Swift SVN r20586
unexpected forematter from the superclass.
This requires a pretty substantial shift in the
generic-metadata allocation/initialization dance
because (1) we can't allocate class metadata without
knowing what the superclass is and (2) the offset
from the metadata cache entry to the address point is
no longer determined solely by the metadata pattern.
While I'm making invasive changes to metadata, fix
two race conditions in metadata creation. The first
is that we need to ensure that only one thread succeeds
at lazily creating a generic-metadata cache. The second
is that we need to ensure that only one thread actually
attempts to create a particular metadata; any others
should block until the metadata is successfully built.
This commit finishes rdar://17776354. LLDB will
need to adjust to the runtime-private metadata layout
changes.
Swift SVN r20537
a flags field, add an instance address point field, and reserve
some additional space.
This change must be coordinated with a corresponding change
to ObjC runtime bits in libarclite; without this, dynamic
subclassing features like KVO will break.
The actual contents of the new fields can change without
bothering the ObjC runtime.
Swift SVN r20183
I've put these fields on the class object for now, just
so we can at least theoretically update them. A superclass
that grew left rather than right could maybe even be made
to work with this schema, but probably not.
rdar://16705821
Swift SVN r16880
Set up a metadata cache for existential type metadata. Instantiate existential metadata by first sorting the protocol list, so that it is order invariant, precomputing the overall witness table count and class constraint of the composition so it can be cached in the existential metadata.
We still need to implement value witnesses for existential containers in the runtime before this is complete. We can at least test the uniquing and flags computations at this point.
Swift SVN r9727
The principal difficulty here is that we need accessing the
value witness table for a type to be an efficient operation,
but there (obviously) isn't a VWT field for ObjC classes.
Placing this field after the metatype would tend to bloat
metatypes by quite a bit. Placing it before is best, but
it introduces an unfortunate difference between the address
point of a metatype and the address of the global symbol.
That, however, can be fixed with appropriate linker support.
Still, for now this is rather unfortunately over-subtle.
Swift SVN r3307
1) Move the low-level runtime code into swift/runtime
2) Move the high-level "standard library" code into swift/stdlib
The key difference is that the 'runtime' contains language support logic
(like retain/release logic) that the compiler assumes to always exist
and may assume intimate details about the implementation. This library
will have intimate knowledge of the swift ABI.
In contrast, the 'stdlib' can be completely rewritten and the
language/compiler make little if any assumptions about it. It is
expected to reexport fundamental types and operators, and implement
fundamental policies (precedence, implicit conversions, etc).
Swift SVN r3045
1) Move httpd to examples where it belongs.
2) Build examples on a regular basis for now.
3) Move low-level runtime source to a sub directory.
Swift SVN r3040
swift_getGenericMetadata. Mostly ripped off clang's
support for same. I did not feel confident in pulling
over the CMake equivalents, so someone else will need to.
Swift SVN r2982
