We use three tag bits on Expr*, Stmt*, Decl*, TypeBase* and SILTypeInfo*, and four on DeclContext*, so set the alignment of the pointed-to types formally with alignas(N) instead of relying on operator new passing down the right alignment to the allocator. Get rid of the informal T::Alignment members of these classes and pass alignof(T) to their allocators. Fix the 'operator new' of DeclContext subclasses so that we can actually use the four tag bits PointerLikeTypeTraits<DeclContext*> claims are available.
Swift SVN r4587
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
Types synthesized by the ClangImporter need to be visited at a minimum by TypeChecker::validateTypeSimple in order to set up generic substitutions and protocol conformances, so arrange for the ClangImporter to pile all of its emitted types into a list that can then be walked by the TypeChecker.
Swift SVN r3901
Note that the constructors we emit don't function yet, since they rely
on the not-yet-implemented class message sends to Objective-C
methods.
Swift SVN r3370
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
and Int[].
Type resolution for types named in ExtensionDecls remains a part of name-binding; it has to use more restrictive rules because we can't perform general member lookup until
we've resolved all the types named in ExtensionDecls.
Swift SVN r2313
I haven't really carefully considered whether existing type-checking etc. is correct for the main module (I think the name-binding rules need to be a bit different?), but it seems to work well enough for the obvious cases.
This is enough to get the one-liner "println(10)" to print "10" in "swift -i" mode, although the path to swift.swift still needs to be explicitly provided with -I.
Swift SVN r1325
This is horribly hack and slash (but enough to pass all tests) for a few reasons:
- I've #if 0'd out the tendrils of the old code
- This handles *just* what was handled before instead of being more general
- We don't have an llvm::MutableArrayRef type, so there is some really gross
const_cast'ing and other struggles to deal with its absence.
Swift SVN r1050
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
Module class. Add a new Module.cpp file to implement this (along with
the existing caching strategy, if you're curious). This eliminates the
parallel 'ModuleProvider' heirarchy.
Swift SVN r802
