When we emit a witness table, build a protocol conformance record for it, and emit the list of all conformance records into a "__swift1_proto" section of the data segment.
Swift SVN r22939
We want to use the reserved space in the metadata pattern for protocol conformance caching, and this link lets us find the metadata pattern from an instance of the generic type.
Swift SVN r22898
This is a type that has ownership of a reference while allowing access to the
spare bits inside the pointer, but which can also safely hold an ObjC tagged pointer
reference (with no spare bits of course). It additionally blesses one
Foundation-coordinated bit with the meaning of "has swift refcounting" in order
to get a faster short-circuit to native refcounting. It supports the following
builtin operations:
- Builtin.castToBridgeObject<T>(ref: T, bits: Builtin.Word) ->
Builtin.BridgeObject
Creates a BridgeObject that contains the bitwise-OR of the bit patterns of
"ref" and "bits". It is the user's responsibility to ensure "bits" doesn't
interfere with the reference identity of the resulting value. In other words,
it is undefined behavior unless:
castReferenceFromBridgeObject(castToBridgeObject(ref, bits)) === ref
This means "bits" must be zero if "ref" is a tagged pointer. If "ref" is a real
object pointer, "bits" must not have any non-spare bits set (unless they're
already set in the pointer value). The native discriminator bit may only be set
if the object is Swift-refcounted.
- Builtin.castReferenceFromBridgeObject<T>(bo: Builtin.BridgeObject) -> T
Extracts the reference from a BridgeObject.
- Builtin.castBitPatternFromBridgeObject(bo: Builtin.BridgeObject) -> Builtin.Word
Presents the bit pattern of a BridgeObject as a Word.
BridgeObject's bits are set up as follows on the various platforms:
i386, armv7:
No ObjC tagged pointers
Swift native refcounting flag bit: 0x0000_0001
Other available spare bits: 0x0000_0002
x86_64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0001
Swift native refcounting flag bit: 0x0000_0000_0000_0002
Other available spare bits: 0x7F00_0000_0000_0004
arm64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0000
Swift native refcounting flag bit: 0x4000_0000_0000_0000
Other available spare bits: 0x3F00_0000_0000_0007
TODO: BridgeObject doesn't present any extra inhabitants. It ought to at least provide null as an extra inhabitant for Optional.
Swift SVN r22880
layouts. Introduce new SIL instructions to initialize
and open existential metatype values.
Don't actually, y'know, lift any of the restriction on
existential metatypes; just pointlessly burn extra
memory storing them.
Swift SVN r22592
Rename the existing misleadingly-named "isClassType" to "isClassObject", and document that it refers to (swift or ObjC) class objects, the latter of which aren't always type metadata.
Swift SVN r22153
Somehow this got out of sync, and IRGen's idea of which flag it was collided with "hasExtraInhabitants", causing hilarity to ensue whenever weak or protocol types were packed in optionals. Fixes rdar://problem/17814752.
Swift SVN r21803
pass the size and alignment of each field. Take advantage
of this to pass a constant size and alignment when
possible.
This avoids the need to recursively find type metadata for
every field type, allowing generic recursively-structured
classes to be built. There are a number of more complicated
cases that this approach isn't good enough for, but this
is good enough for now to fix rdar://18067671.
Also make an effort to properly support generic subclasses
of Objective-C classes.
Swift SVN r21506
initializeBufferWithTakeOfBuffer value witness.
Attempt to use initializeBufferWithTakeOfBuffer in
some appropriate places.
There are some changes enabled by this which are
coming in a follow-up patch.
Swift SVN r20741
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
lldb needs this to be able to tell how many generic parameters are actually needed to instantiate a generic type. Fixes <rdar://problem/17425286>.
Swift SVN r19573
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
Revert "[stdlib] Use an enum for ArrayBuffer storage"
This reverts commit r18996.
This reverts commit r18954.
The optimizer is not ready yet to handle this change especially given
the time until Beta 3. After speaking with DaveA, we agreed to revert
this and take such large changes onto private branches until we are sure
that the optimizer is ready to handle them rather than risking
performance regressions due to hitting the "optimization cliff".
Swift SVN r19026
Also update ArrayBuffer to take advantage of it.
This change allows us to pass a word-sized enum with a native object
reference payload directly to the runtime, without switching on the enum
to unwrap the contents. Even though that unwrapping was semantically
equivalent to bit masking, it was causing fits in the optimizer.
Swift SVN r18996
This is the most general dynamic cast operation, permitting
arbitary source and destination types and handling arbitrary
changes in representation. A value of the destination type
is constructed in an address provided by the caller; flags
control the behavior w.r.t. the source value.
Not yet used; probably buggy in various particulars.
Swift SVN r18815
Don't use spare bits on platforms that use ObjC tagged pointers when an enum payload involves a class-constrained existential, archetype, or ObjC-defined class type. If a payload is of a Swift-defined class type, we can still assume it's a real pointer and use its spare bits. Add an @unsafe_no_objc_tagged_pointer attribute that can be applied to protocols to denote that existentials bounded by that protocol can use spare bits; this is necessary to preserve the layout of bridged Array and Dictionary types, which should not be bound to tagged pointer types in practice (fingers crossed). Fixes <rdar://problem/16270219>.
Swift SVN r18781
dynamicCastClass assumes that the destination type is a
Swift class type.
dynamicCastObjCClass assumes that the destination type is
an ObjC class type (represented as ObjC metadata, not type
metadata).
dynamicCastUnknownClass assumes only that the destination
type is some kind of class.
Swift SVN r18776
Blocks need their own type metadata with value witnesses appropriate to the block representation. Fixes <rdar://problem/16918740> and <rdar://problem/16981126>.
Swift SVN r18508
UIViewController is able to find nib files that have names derived from the
UIViewController subclass's name. This change modifies UIViewController's
lookup so it is able to find nib files for Swift class names.
Swift SVN r18470
This allows us to, for example, convert an array of unchecked
optionals of some bridged type T to NSArray. It's a runtime failure if
the unchecked optional contains nil.
This is most of <rdar://problem/16899681>, but I want to improve the
testing and look into the various FIXMEs.
Swift SVN r18106
for extra inhabitants.
For structs in particular, this eliminates a major source
of abstraction penatlies. For example, an optional struct
containing an object pointer is now represented the same
way as an optional object pointer, which is critical for
correctly importing CF types as Unmanaged<T>!.
In time, we should generalize this to consider all elements
as sources for extra inhabitants, as well as exploiting
spare bits in the representation, but getting the
single-element case right really provides the bulk of the
benefit.
This commit restores r17242 and r17243 with a fix to use
value witnesses that actually forward the right type metadata
down. We were already generating these value witnesses in
the dependent struct VWT pattern, but I was being too clever
and trying to use the underlying value witness directly.
Swift SVN r17267
This reverts commit r17243. We can't just forward the extra inhabitant payloads
from a field, because they will end up receiving metadata for the incorrect
type and crashing.
Swift SVN r17251
extra inhabitants.
Obviously this should eventually be generalized to
take from any element, but this is good enough to
give us zero-cost abstraction via single-field structs.
Contains some bugfixes for the tuple-extra-inhabitant
changes as well, because test coverage for optional
structs is obviously quite a bit richer than for
optional tuples.
All of this is leading towards unblocking IRGen for
importing CFStringRef as Unmanaged<CFString>!.
Swift SVN r17243
Set a bit for types that are non-bitwise-takable, and calculate it as part of runtime struct and enum layout. Include 'bitwise takable' as part of the runtime 'is inline' calculation to be consistent with the compile-time policy change in r17008.
Swift SVN r17036
Until we lock down the Swift ABI and ship with the OS, we need to be resilient
in the face of ObjC dynamic subclassing and OS changes. In practice, this means
that we need to have a swift runtime ABI to read the isa out of objects. I've
added it as of r. See: swift_getClassMetadata()
We can and will optimize swift_getClassMetadata into a single instruction once
we lockdown our ABI and ship with the OS.
See also: <rdar://problem/16735599>
Swift SVN r16889
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
We really don't need to support individual objects
this large, much less more than 4 billion fields in
a single type.
Also rearrange the fields to bring the instance
size/alignment fields closer to the class header,
just for a minor locality win.
Swift SVN r16879
