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
Think the scenarios through more carefully, create more reliable tests.
Fixes <rdar://problem/16105759> Too many retains for COW optimization
Swift SVN r14140
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
Please never call malloc/calloc/free directly in the stdlib/runtime now.
<rdar://problem/16104269> Fix 16023119 the right way -- make all runtime entry points use the malloc cache
Swift SVN r14091
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
Will serve as an IndexType for CollectionOfOne<T>
Open Question: should this become a full-fledged Int1 type, generated by
FixedPoint.gyb?
Swift SVN r13974
Sometimes you just need to normalize to the widest integer
type (especially in generic code), and who knows; someday we may get
Int128 back.
Swift SVN r13950
Force @objc_blocks to use the @cc(cdecl) calling convention, so that calling them undergoes bridging conversions in SILGen, and give them the correct ownership conventions so that the callee, arguments, and result are passed +0. This unfortunately ruins our ability to verify bridge_to_block instructions at all, but bridge_to_block is a hack anyway, and this is a necessary prerequisite to actually being able to call blocks in IRGen.
Swift SVN r13923
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
As part of this, have the standard library target be responsible for
symlinking Clang's headers into the resource directory, instead of the
compiler target. This makes sure the headers show up in all copies of
the build directory.
This brings our iOS testing closer to what Xcode will do, which will
hopefully avoid issues like <rdar://problem/16052579>.
Swift SVN r13890
This was supposed to be done a long time ago after DI landed, but a
weird bug in our getopt wrapper blocked this. That code is gone now, so
let's make the switch.
Swift SVN r13786
Every Swift module starts with an implicit "import swift", so why not use
that to hold all of the runtime info we need?
This only gets us copying the header (and its module map) into include/swift/.
It doesn't actually use it yet.
Swift SVN r13617
This re-applies r13380, reverted in r13406. I don't think this actually
caused any harm (r13400 was the primary culprit), but if it did I'd
like to actually see the buildbots or someone else's machine fail on it.
Swift SVN r13456
This substitutes swift_driver in as the new "swift". Tests that currently
test "%swift" will invoke "swift -frontend", much like "clang -cc1".
Most command-line interaction will look the same, except that Swift can
now emit linked libraries (using -emit-library) and executables (using
-emit-executable, or by not passing a mode option at all).
If you are working with @transparent functions, note that they will not be
properly inlined across file boundaries unless you use
-force-single-frontend-invocation, which emulates the old swift binary.
There are Radars for this already: <rdar://problem/15366167&15693042>
The name 'swift_driver' is now a symlink for 'swift'. This will be removed
next week.
The old 'swift' is still available as 'swift_old', though it is not being
tested at all. This will be removed in two weeks.
Clean CMake builds will get this immediately.
Incremental CMake builds will not get the new driver unless you explicitly
enable the SWIFT_NEW_DRIVER option (-DSWIFT_NEW_DRIVER=ON on the command line).
This option will go away in a week.
Makefile builds will get this immediately because I didn't want to work out
how to maintain both modes.
Much credit to Connor for bringing up the entire driver and for doing much
of the work in ensuring that all the tests continue to pass.
Swift SVN r13380
