When an Objective-C class is first used, the runtime will "realize" it,
i.e. create the rw-data and set a couple flags. With pure Swift classes,
though, it's possible to create an instance and then send a message to it
without ever sending a message to the class, in which case the runtime will
try to realize the /instance/ and mess everything up.
This patch "fixes" that by sending the +load message to all Swift classes,
to make sure they get realized before being used. This is a very
unfortunate cost in startup time but will be necessary for id-compatibility.
I will admit that I'm not sure why this is necessary for compiled classes.
I would have expected the object file to contain the necessary information
for the runtime to realize the classes in it by default. But perhaps
classes aren't realized until their first class message even in statically-
compiled code.
<rdar://problem/13154445>
Swift SVN r3951
This allows you to print imported structs that were defined as 'typedef struct foo {} foo;', for which the original decl is otherwise inaccessible:
swift> :print_decl NSFastEnumerationState
typealias NSFastEnumerationState = NSFastEnumerationState
struct NSFastEnumerationState {
...
}
Swift SVN r3922
The lexer now models tuples, patterns, subscripting, function calls, and
field access robustly. The output tokens are now better named as well:
l_paren and l_paren_call, and l_square and l_square_subscript. It
should be much more clear now which one to use. Also, the use of
l_paren or l_square will not arbitrarily flip flop if the token before
it is a keyword or if the token before it was the trailing ']' of an
attribute list. Similarly, tuples will always cause the lexer to produce
l_paren, regardless if the user typed '((x,y))' or '( (x,y))'.
When we someday add array literals, the right token is now naturally
falling out of the lexer.
Swift SVN r3840
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
