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
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
static method to call it, to make it more explicit what is happening. Avoid
using TypeLoc::withoutLoc for function definitions; instead, just use an empty
TypeLoc.
Swift SVN r2606
protocols the underlying type of the type alias shall conform to. This
isn't super-motivating by itself (one could extend the underying type
instead), but serves as documentation, makes typealiases provide the
same syntax as other nominal types in this regard, and will also be
used to specify requirements on associated types.
Swift SVN r2133
multiple times, as well as teaching the name lookup mechanism that
it's similarly rude to report ambiguous results because it searched
the same import twice. Fixes <rdar://problem/11287213>.
Yes, this is a bit of an ugly hack.
Swift SVN r1610
Unlike Type, it implements equality operators. It is returned by Type->getCanonicalType().
This adopts it in the minimal places required to get the build to work, it would also be nice
to switch IRGen to canonical types and use it there.
Swift SVN r1298
making it a real part of the AST. Also, rework TUModuleCache to do its computation
when it is constructed, instead of trying in each query.
Swift SVN r809
