The hack to get the LLVM build system to do what we want is to define a
custom build rule for "XYZ.o" and then add "XYZ" as a dummy source file
to the SOURCES variable, which the LLVM Makefile system uses. To make it
clear that something unusual is going on here, I've changed all existing
instances of this to use "XYZ.o" in SOURCES, rather than having that name
be derived from "XYZ.swift" or whatever.
The actual Swift source files go in SWIFT_SOURCES for the time being
(and possibly forever, since Swift sources will always be built together).
Swift SVN r11058
Since our build system isn't really set up to cope with
multi-sourcefile-modules, dump all Foundation support directly into
Foundation.swift
Swift SVN r11049
Because we're using a "brute-force" combination of conversion to
NSString and forwarding, this code will continue to work when String
is replaced by NewString. It may not be fast yet, but at least it
will flesh out the experience for Cocoa programmers
Swift SVN r11034
Instead of letting swift_NSStringToString leak malloced memory, use swift_allocPOD to allocate storage for the converted String, and stash the heap object into the created string.
Swift SVN r7872
This ended up being easiest with a runtime function. I couldn't push this
into the standard library because the standard library doesn't know about
NSObject, and I couldn't compile the ObjectiveC module as -parse-stdlib
because it uses standard library types and doesn't otherwise know how to
find the "swift" module.
Swift SVN r7581
...rather than as a separate step. This avoids duplicating Parse and Sema
work for these. (This is the new and correct version of r7377.)
Also, remove leftover code for building "swift.swift" and friends in lieu
of proper modules. We're not going back to those days. :-)
Swift SVN r7420
It's used for class-bounded protocols, not just Foundation objects.
No test because I couldn't figure out how to write a non-compilation test.
Swift SVN r7367
