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
This change removes a broken simulator hack because we don't enable the
fast cache for the simulator anymore, and even if we did, ALLOC_CACHE_COUNT
must be 56 or 64, not 32 (for 32-bit and 64-bit respectively).
Swift SVN r14447
A useful unsafe optimization for potential implementations of Mirror that have existing heap storage to share from the value, like for Array or Dictionary.
Swift SVN r14186
Define a "Mirror" protocol with methods for querying the number of children a structured value has, getting the name and mirror for each of those children, and a string and "IDE representation" of the value, as needed by playgrounds and by our planned generic printing facility.
In the runtime, define a "reflect" function that can provide a Mirror for any object, either using a "Reflectable" protocol conformance if available, or falling back to a magic implementation in the runtime that grovels the type metadata. Stub out a bare minimum default implementation.
Swift SVN r14139
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
Mock up a naive Printable protocol, and do some dirty tricks in the runtime to implement a 'printAny' function that uses swift_conformsToProtocol to look up a conformance to Printable if the type has one, or falls back to a dumb opaque printing if it doesn't. Use this to make Array<T> Printable in some way or another for all T.
Swift SVN r13902
Given our constraints for 1.0, we can actually sort-of look up protocol conformances just by dlsym'ing the symbol for their protocol witness table, since we won't be implementing runtime witness table instantiation or private conformances anytime soon. To make this work for generic types, distastefully regress our mangling for protocol conformances by assuming all generic conformances are completely general to the unbound generic type and leave the generic parameters out of the mangling.
Swift SVN r13901
This lets IRGen avoid emitting an alloca for common generic metadata instantiations. These entry points can also be marked "readnone", and the general getGenericMetadata entry point can be "readonly", giving LLVM's optimizer a fighting chance on unspecialized generic code.
Swift SVN r12789
