Playground and array bridging code spends a lot of time here, so instead of brazenly dlsyming each and every time we want to look up a conformance, cache results in a DenseMap. <rdar://problem/16809482>
Swift SVN r17464
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 r17242. We can't simply forward tuple element extra
inhabitant witnesses for the same reason laid out in the previous commit.
Swift SVN r17252
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
extra inhabitants.
This is obviously not as general as it should be,
but it actually helps a lot.
I started doing enums assuming it would teach me
something about how to do it for structs, and it
kindof worked.
Swift SVN r17242
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
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
As it turns out, Swift classes can stumble into having a non-pointer isa.
This might be a problem for 1.0, but that is beyond the scope of this bug.
Swift SVN r16721
The cost of hacks to swift_conformsToProtocol is starting to outweigh any benefit to being principled here. We'll get a linker error now if multiple modules declare a conformance for the same type to the same protocol, but that's arguably a good thing for 1.0 anyway, since we aren't set up to get that right in other ways.
Swift SVN r16554
The strategy we are using is to obtain the class name from the ObjC runtime (as apparently nominal type descriptor for ObjC-wrapped types do not contain a useful name string) and then crafting the appropriate mangled name for the witness
Also, make AppKit another source of conformances. We currently have custom conformances for Reflectable that we are in Foundation (NSURL) and AppKit (NSView) - if more modules need to have custom mirrors, we might end up having to expand the list
Swift SVN r16280
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
Make these three types conform to the BridgedToObjectiveC
protocol, which is needed for array bridging. This is one part of
<rdar://problem/16533359>.
Because this must happen in the Foundation module, hack
swift_conformsToProtocol to look in the Foundation module for
conformances when it can't find them in the module corresponding to
the type. This is an egregious hack to an egregious hack, but it gets
us closer.
Swift SVN r15997
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
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 is easier for out-of-process clients like LLDB or DTrace to understand, and will let us mess with the runtime metadata cache data structure without forcing churn on the debugger team.
Swift SVN r13221
Using a linked list for metadata caches is pretty lame. Pull in llvm::DenseMap and hash_combine_range and use them to index instantiated metadata.
The previous attempt at this failed because tuple type metadata was laid out in a way that smashed the metadata cache key. Cache keys used to be laid out like this:
CacheEntry struct
-----------------
cache key
-----------------
variable-sized payload
And TupleTypeMetadata tried to tail-emplace its element array immediately after the main CacheEntry, forgetting the cache key was there. When we actually try to use that cache key to implement a hash table, bad things happen. Rearrange cache entries into the less error-prone layout:
cache key
-----------------
CacheEntry struct
-----------------
variable-sized payload
This also nicely avoids the need for a dynamic offset from the CacheEntry struct to its payload. A tail-allocated payload is likely to be more hot than the cache key, which is only needed at instantiation and lookup time.
Swift SVN r13205
Using a linked list for metadata caches is pretty lame. Pull in llvm::DenseMap and hash_combine_range and use them to index instantiated metadata.
Swift SVN r12998
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
