We need a custom but simple map table for two reasons:
1) To precisely control our allocations to avoid reentrancy via Instruments.
2) To prepare for out-of-process introspection via Mach VM calls.
This fixes: <rdar://problem/16718231> Swift allocator must not call malloc nor global operator new
Swift SVN r17769
This is to be used by playgrounds to provide a better sidebar representation of web pages than simply showing the URL text
Part of rdar://16799088
Swift SVN r17710
Apparently Builtin.fixLifetime isn't yet respected
(<rdar://problem/16464507>) and calls to that and swift_keepAlive were
getting scattered around randomly. Let's have a convenient library
function instead.
Swift SVN r17493
DaveZ says: In the future we're likely to store "associated objects,"
which will make inlining the introspection of the reference count
problematic.
Swift SVN r17481
We still want to send out image data for those, but UI consumers need to be able to differentiate - should they so desire - a true image from a software sprite rendered in pictorial form
Part of the fix for rdar://16806238
Swift SVN r17471
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
This tag is meant to trade in image data, but be explicit about the fact that this is a "screenshot" of a UI view rather than a plain ol' picture
Fixes the swift library part of rdar://16796532
Swift SVN r17390
This change adds a new variant of "addObserver:forKeyPath:options:context:"
that takes a "KVOContext" instead of an unsafe void*. The variant
delegates to the original method, but first 'retain's the object
before turning it into an unsafe pointer. The API is then matched
with a variant of 'removeObserver:forKeyPath:context:' which
delegates to the original method and then 'release's it.
This vision here is that Swift clients of this API will use this
variant, and not the unsafe one. A refinement (later) is to
not expose the original methods at all, and provide a new method
'observeValueForKeyPath:ofObject:change:kvoContext:' that implements
a thunk that delegates to 'observeValueForKeyPath:ofObject:change:context:'
and does the void* cast (which the code in the test case does).
This needs to go through API review; names are strawman names.
Swift SVN r17325
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
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
* Temporarily turn on -link-objc-runtime by default. This will be
removed again in rdar://16753644.
* Symlink XcodeDefault.xctoolchain's copies of arclite into the Swift build's
resource directory so tests can see it.
* Enable the KVO test.
Swift SVN r17132
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
However, this broke for Swift subclasses of NSString because the Swift mirror took precedence over the ObjC NSString choice
Notably, it broke for NSContiguousString
This patch fixes that by explicitly making NSString reflectable, so that its subclasses will automagically do the right thing here
Fixes rdar://16758974
Swift SVN r17059
This is meant to represent to UI consumers the notion of a logical truth value
Previously, we were using a String case to represent such values, but that loses potentially useful information to UI layers
This fixes rdar://16719431
Swift SVN r17037
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
StringByteData was legacy detritus containing an in-memory UTF8
representation of a Swift string. Since we switched to a UTF16 base
representation, use the new stuff in StringUTF8 instead.
Swift SVN r16968
We need something here so we can rip out StringByteData. Ideally this
would have BidirectionalIndex'es, but this will do for now. It has to
be a Collection so we can represent its multi-pass-ness.
Swift SVN r16966
