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
Rather than go through reentrant and problematic contortions to make Swift
work with the existing Instruments hooks, they agreed to just patch some
globals that we provide to get their logic to be activated.
Swift SVN r17144
Someday we'll have time to disentagle the real mangler from the rest of the compiler. For now, this is a hack.
<rdar://problem/16671220> Add a simple mangler API just for handling "Module.ClassName" and "Module.ProtocolName" cases
Swift SVN r17066
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
There's still a lot of manual intervention required, but
at least we don't have the constants written in two different
places.
Should be NFC.
Swift SVN r15242
Building the field type vector is potentially expensive and the vector isn't needed unless we do reflectiony things to a type, so let's use a lazy accessor. Make room for it, but don't populate it yet, so we can deal with fallout from the metadata layout change.
Swift SVN r15194
They aren't buying us anything until we thread through the custom ABI
work into Swift. I'm told this won't happen for a while. Until then,
they're just double the intermediate work in this area.
Swift SVN r15004
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
Implicit conversions to and from an unsigned long long enum class give us the calling convention we want for swift_allocBox without totally destroying the API for C callers.
Swift SVN r14919
For ObjC classes, use class_copyIvarList to walk the ivars, and produce the summary string using -debugDescription. Still to come:
- visiting the base class as a child, and
- calling -debugQuickLookObject to get the quicklook object. Still waiting on a final design for the IDERepresentation API.
Swift SVN r14626
