Walk backward from a '.' through balanced () [] <> to find context. Fix a problem with parseCompletionContextExpr where UnresolvedIdentifierTypes wasn't getting properly transferred to the TranslationUnit after parsing, causing 'Foo<T>.' completion to blow up.
Swift SVN r4075
If the completion prefix has a '.' behind it, guesstimate a context expression by lexing backward through an identifier(.identifier)* dotted path, then attempt to parse and typecheck that expression to decide on a base type in which to find completions.
Swift SVN r4063
Integrating Clang's FindVisibleDecls with Swift's by importing every decl created too much per-repl-entry compile time overhead, so as a workaround, just wire completions directly to FindVisibleDecls on the clang translation unit itself. Unfortunately this means we get completions for things Swift can't import yet, but it also means we don't have to wait 30 seconds to compile every entry after doing a completion.
Swift SVN r4061
Implement a 'lookupVisibleDecls' API similar to Clang's that replicates the UnqualifiedLookup logic for walking through a given scope looking for decls. Use it to populate the completion list in the repl.
Still to be done: Clang module lookup via Clang's lookupVisibleDecls, and context deduction from dotted path expressions.
Swift SVN r4056
This may not be what we want to do in the long run, but for now it makes
development that much easier. If you want to test behavior with no SDK
available, please explicitly pass -sdk= to swift.
Swift SVN r4019
Actually indent the source lines we receive from editline when we store them to the buffer so that :dump_source looks right. Fixes <rdar://problem/13171743>.
Swift SVN r3983
Set up a Completion object to extract context and a prefix string from a partial input and then track the state of the user's interaction with the completion system. Wire up tab in editline to trigger completion when pressed. It still needs to be hooked up to name lookup; right now it just looks in a fixed list of completion strings.
Swift SVN r3981
In theory this would colorize the prompt, but editline is broken and doesn't emit literal-mode characters in sequence with cooked characters.
Swift SVN r3973
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 patch makes it so we substitute 'main' instead of warning. Eventually
we probably want to make this an error in library mode and a pedantic
warning in script mode.
Swift SVN r3516
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
From a user's perspective, one imports Clang modules using the normal
Swift syntax for module imports, e.g.,
import Cocoa
However, to enable importing Clang modules, one needs to point Swift
at a particular SDK with the -sdk= argument, e.g.,
swift -sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9M.sdk
and, of course, that SDK needs to provide support for modules.
There are a number of moving parts here. The major pieces are:
CMake support for linking Clang into Swift: CMake users will now need
to set the SWIFT_PATH_TO_CLANG_SOURCE and SWIFT_PATH_TO_CLANG_BUILD
to the locations of the Clang source tree (which defaults to
tools/clang under your LLVM source tree) and the Clang build tree.
Makefile support for linking Clang into Swift: Makefile users will
need to have Clang located in tools/clang and Swift located in
tools/swift, and builds should just work.
Module loader abstraction: similar to Clang's module loader,
a module loader is responsible for resolving a module name to an
actual module, loading that module in the process. It will also be
responsible for performing name lookup into that module.
Clang importer: the only implementation of the module loader
abstraction, the importer creates a Clang compiler instance capable of
building and loading Clang modules. The approach we take here is to
parse a dummy .m file in Objective-C ARC mode with modules enabled,
but never tear down that compilation unit. Then, when we get a request
to import a Clang module, we turn that into a module-load request to
Clang's module loader, which will build an appropriate module
on-the-fly or used a cached module file.
Note that name lookup into Clang modules is not yet
implemented. That's the next major step.
Swift SVN r3199
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
