Update everywhere in Swift that refers to this module accordingly.
This change is backwards-incompatible and will require rebuilding any
Objective-C-based object files. I recommend a clean of swiftFoundation
and NSStringDemo at the very least. The swiftObjC target is also being
renamed to swiftObjectiveC for consistency.
Swift SVN r3784
Will allow immediate execution through SIL-irgen when SIL-irgen actually exists. Also add NeedsOutput_{First,Last} symbols to the ActionType enum so that the insidious enum ordering significance there is more obvious.
Swift SVN r3757
It doesn't do anything but crash yet. Also add an entry point fo SILGen to Subsystems so that it can be invoked without dependency on SIL or SILGen.
Swift SVN r3738
This change allows client code to just use, e.g.,
import Foundation
to get both the Clang Foundation module and the Swift Foundation
module that provides various adaptation (typically via
extensions). At some point later, we can consider whether the modules
will end up in different namespaces somehow, or whether this is best
tackled by some kind of module re-export directive, but for now it's
convenient while we await the design of a real module system for
Swift.
Swift SVN r3405
When generating IR for the JIT, use sel_registerName() to unique the
selector references we generate. Static code doesn't need this
pessimization. Fixes <rdar://problem/12764732>.
Swift SVN r3403
This is a horrible, hard-coded hack so that the REPL and interpreter
will get the ObjC bridging definitions from the SwiftFoundation dylib
when the SwiftFoundation module is imported.
Swift SVN r3402
This particular command is useful for exploring the ASTs generated by
the Clang importer. For example
import Cocoa
:dump_decl NSArray
shows all of the imported methods in both NSArray (which only has two
methods) and its categories (which have many, many methods).
Swift SVN r3275
There is no protection whatsoever if the Clang-to-Swift type
conversion produces something that Swift doesn't lower in an
ABI-compatible way. That will be dealt with later.
Swift SVN r3249
1) Move the low-level runtime code into swift/runtime
2) Move the high-level "standard library" code into swift/stdlib
The key difference is that the 'runtime' contains language support logic
(like retain/release logic) that the compiler assumes to always exist
and may assume intimate details about the implementation. This library
will have intimate knowledge of the swift ABI.
In contrast, the 'stdlib' can be completely rewritten and the
language/compiler make little if any assumptions about it. It is
expected to reexport fundamental types and operators, and implement
fundamental policies (precedence, implicit conversions, etc).
Swift SVN r3045
rely at all on the existing type checker. Instead, just fold sequence
expressions (which are effectively a delayed parsing phase) and then
hand off the expression to the constraint solver.
Allows us to type-check expressions with operators, e.g., f + 1.
Swift SVN r2793
generation from an expression that has not been type-checked. One can
see the constraints introduced by an expression by using
:dump_constraints <expression>
within the REPL. We're still missing several major pieces of
constraint generation:
- We don't yet "open up" references to polymorphic types
- We don't print out the child constraint systems in the dump, so
it's not at all obvious what happens within overloading (and I'm not
convinced I like my representation anyway)
- There are no tests whatsoever
- Member constraints are still very, very weird
Swift SVN r2624
This should be enough to allow statically compiling swift applications. As followups, I'm going to additionally start installing swift.swift to a common location, and start making REPL/script mode aware that these functions are available, so they don't bother to IRGen them.
I'm leaving around some files in runtime/ which aren't necessary with this commit; I'll delete them in a separate commit.
Swift SVN r1725
