...and use it to load frameworks and libraries in immediate modes (-i and
the REPL), replacing a walk of visible modules that checked if any imported
modules were Clang modules.
Swift SVN r7488
...instead of just those that are re-exported. This will be used for
autolinking (and probably few other places).
As part of this, we get two name changes:
(1) Module::getReexportedModules -> getImportedModules
(2) TranslationUnit::getImportedModules -> getImports
The latter doesn't just get modules-plus-access-paths; it also includes
whether or not the import is re-exported. Mainly, though, it just didn't
seem like a good idea to overload this name when the two functions aren't
really related.
No tests yet, will come with autolinking.
Swift SVN r7487
ClangImporter::create had a 'weak' attribute but it did not actually have the desired effect,
static libraries still want to link to ClangImporter::create if it is used.
Avoiding linking ClangImporter kinda "worked" because CompilerInvocation::setSDKPath was inline,
so if you didn't call it then you didn't need to link to Clang importer, but that is avoiding
ClangImporter statically, not dynamically.
You could see this by moving CompilerInvocation::setSDKPath out-of-line and then sil-opt would fail to link.
In order to have clients avoiding linking Clang, introduce NullClangImporter which just returns null for the
ClangImporter constructor function.
Swift SVN r7465
This will be used to resolve properties and method calls on objects with
dynamic-lookup ("id") type. For now, this is tested in swift-ide-test
by using the -dynamic-lookup-completion option and providing a
-code-completion-token value.
Caveats/TODOs:
- As before, since we're using the global method pool, this isn't scoped by
module. We could do a per-module filter, but I don't know if that will
actually buy us much.
- Again, Clang's method pool does not include methods from protocols.
- Lookup by selector name cannot find properties with a customized getter
name. <rdar://problem/14776565>
- The Clang-side method pool is keyed by selector, but Swift wants to look
things up by method name, which maps to the first selector piece, so we
end up having to do a scan of all the selectors in the pool.
Swift SVN r7330
Caveats / TODOs:
- Since we're using the global method pool, this isn't scoped by module.
We could do a per-module filter, but I don't know if that will actually
buy us much.
- Clang's method pool does not include methods from protocols.
- This requires importing every single method found into Swift's AST just
to print them in the completion results.
Swift SVN r7329
Before this change, DeclContext of all imported decls was set to the first
imported module.
No tests now, will be tested by future code completion commits.
Swift SVN r6949
Now that we have true serialized modules, the standard library can import
the Builtin module without any special direction (beyond -parse-stdlib),
and anyone can include those modules without special direction.
Swift SVN r6752
This closes out <rdar://problem/14513108> -- sil-opt no longer depends on
ClangImporter or any Clang libraries. In theory, however, forcing a load
of a libSwiftClangImporter.dylib would allow sil-opt to process SIL files
containing Clang imports.
Swift SVN r6700
This handles both Clang’s transitive inclusion and the use of
"adapter modules" to augment the Clang modules (e.g. Foundation.swift),
at the cost of a bit more memory (used to wrap all the Clang modules
in ClangModule objects). This is paving the way for making Sema
independent of ClangImporter.
Swift SVN r6698
This makes it very clear who is depending on special behavior at the
module level. Doing isa<ClangModule> now requires a header import; anything
more requires actually linking against the ClangImporter library.
If the current source file really can't import ClangModule.h, it can
still fall back to checking against the DeclContext's getContextKind()
(and indeed AST currently does in a few places).
Swift SVN r6695
This involved threading it through ModuleLoader, as with all the other
module-generic callbacks. I plan to collapse a bit of the chaining, but
unfortunately not that much.
This brings back the CodeCompletion tests.
Swift SVN r6527
importing them
Because going through the import for every code completion request is slow,
Clang code completion results are cached in the CodeCompletionContext. The
cache needs to be invalidated whenever a new Clang module is loaded. In order
to implement this, ModuleLoadListener class was added.
Swift SVN r6505
This causes the SourceLoader to recursively parse the imported module in standard
library mode, giving it access to the Builtin module.
This is all a terrible hack and should be ripped out with great victory someday, but
until we have binary modules that persist the build setting used to produce the
module, this is the best we can do.
Swift SVN r5847
This replaces the obscure, inefficient lookup into extensions with
something more straightforward: walk all of the known extensions
(available as a simple list), then eliminate any declarations that
have been shadowed by other declarations. The shadowing rules still
need to consider the module re-export DAG, but we'll leave that for
later.
As part of this, keep track of the last time we loaded extensions for
a given nominal type. If the list of extensions is out-of-date with
respect to the global generation count (which tracks resolved module
imports), ask the modules to load any additional extensions. Only the
Clang module importer can currently load extensions in this manner.
Swift SVN r5223
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
This allows us to add additional module import paths besides those provided
in the sysroot. This is necessary for the demo (so we can import our custom
ScriptingBridge header file) and will probably be needed in some form in the
long run to support mixed Swift/Objective-C projects.
Swift SVN r3721
This importer handles all of the Clang structural types, e.g., builtin
types (int, float, void), function types, block pointer types, and
C pointer types. It does not yet handle nominal types such as enums,
structs, or Objective-C classes, and there are some questions about
(e.g.) array types.
Swift SVN r3212
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
