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
Add value witnesses for destroyArray, initializeArrayWithCopy, and initializeArrayWithTake{FrontToBack,BackToFront}, and fill out the runtime value witness table implementations. Stub out the IRGen ones for now.
Swift SVN r16772
the value buffer comes first.
The motivation for doing this is similar to the
motivation for moving it for class existentials:
it eliminates the need for an offset for the most
common accesses, which is particularly important
for the generic value witnesses.
Also try to hard-code that layout in fewer places,
or at least static_assert the places that have to
do so.
Swift SVN r16279
pointer first.
This most important effect of this is that accesses to that
field don't need to be dynamically offsetted past an arbitrary
number of value witnesses, which is pretty nice for the
generic value witnesses.
Swift SVN r16243
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
