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
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
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
This is part of our poor-man's internal compiler SPI hiding
in the standard library. We don't want these functions showing
up in code completion, etc.
Swift SVN r16916
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
Also fix a latent bug in the logic in the disabled code to scribble over memory durring dealloc.
<rdar://problem/15855042> QoI: abort on resurrection
Swift SVN r16827
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
Currently this prevents building Swift on 10.9.
Right now CrashReportClient.a is used regardless of the SDK being used,
and the CMake logic does a check for the .a across different platforms
and SDKs without checking what the build product target OS actually is.
The current logic somewhat works because the SDKs will be in different
Platforms, but it is fragile.
Swift SVN r16678
