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
This introduces the notion of arenas into ASTContext, with two arenas
currently defined: one for 'permanent' storage, and another for the
current constraint checker. The latter is used when allocating any
types that involve type variables, which are only used temporarily
during type checking anyway.
This gives us a 1% speedup on swift.swift (because we're hitting
smaller hash tables when doing lookups) and < 1% memory reduction
(since that's not the main source of memory usage). It's more
important architecturally, so our memory usage doesn't grow with the
number of type-checks performed.
Note also that this arena scheme could be generalized, which we may
very well want to do in the future. For example, we could easily have
an arena for temporary nodes introduced by parsing (e.g.,
UnresolvedDeclRefExpr) or by name binding (OverloadedDeclRefExpr), and
clear that arena when we successfully move onto the next phase. Or, in
a REPL/debugger context, have a 'temporary' arena for
statements/expressions that can be removed.
Swift SVN r3175
types in a few ways:
- Actually check the extra requirements placed on associated types,
e.g., "T.Element : Ordered"
- Actually encode/store the protocol conformance information for a
BoundGenericType in the same way that we do for SpecializeExpr,
GenericMemberRefExpr, and GenericSubscriptExpr. Yay, consistency.
- Move the storage for the protocol conformance information into a
DenseMap in the ASTContext indexed by canonical BoundGenericType, so
it doesn't require inline storage in BoundGenericType.
Swift SVN r2517
type substitution for a nested type reference (Foo.Bar.Wibble) whose
substituted parent reference (Foo.Bar) yields an archetype can simply
look for the appropriate nested type in the archetype.
This allows us to eliminate the hideous ASTContext::AssociatedTypeMap
and simply the archetype builder.
Swift SVN r2438
functions. This involves a few steps:
- When assigning archetypes to type parameters, also walk all of the
protocols to which the type parameter conforms and assign archetypes
to each of the associated types.
- When performing name lookup into an archetype, look into all of
the protocols to which it conforms. If we find something, it can be
referenced via the new ArchetypeMemberRefExpr.
- When type-checking ArchetypeMemberRefExpr, substitute the values
of the various associated types into the type of the member, so the
resulting expression involves the archetypes for the enclosing
generic method.
The rest of the type checking essentially follows from the fact that
archetypes are unique types which (therefore) have no behavior beyond
what is provided via the protocols they conform to. However, there is
still much work to do to ensure that we get the archetypes set up
correctly.
Swift SVN r2201
using the term "unresolved" in expressions for a while, and it fits
for types better than "dependent type."
The term "dependent type" will likely come back at some point to mean
"involves an archetype".
Swift SVN r1962
archetypes. Use this substitution when checking the
variable/function/subscript witnesses during protocol conformance.
This allows us to check the conforms-to relationship for the Range
protocol as we want to express it.
Swift SVN r1945
wrap it in an 'id' type in the standard library.
Also fix a bug noticed by inspection where initWithTake for
function types wasn't entering a cleanup for the taken value.
This probably doesn't matter for existing possibilities, but
it's potentially important under exceptions.
Swift SVN r1902
This is <rdar://problem/10217868>. Apparently I'm using Lion's
libc++ headers somehow, which I should probably fix; but since
the use of shared_ptr is just a hack until DenseMap supports
move-only types, I don't feel bad about changing it to a different
hack that avoids shared_map altogether.
Swift SVN r1897
protocol Document { var title : String }
protocol Versioning { func bumpVersion() }
protocol VersionedDocument : Document, Versioning { }
This commit covers the basic functionality of protocol inheritance, including:
- Parsing & AST representation
- Conforming to a protocol also requires conforming to its inherited
protocols
- Member lookup into a protocol also looks into its inherited
protocols (results are aggregated; there is no name hiding)
- Teach ErasureExpr to maintain lvalueness, so we don't end up
performing a silly load/erase/materialize dance when accessing
members from an inherited protocol.
Swift SVN r1804
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
and is just an unmanaged pointer. Also, introduce a basic swift.string type.
This is progress towards rdar://10923403 and strings. Review welcome.
Swift SVN r1349
anonymous member is actually one of these.
A func decl is curried over all of its parameter clauses,
as long as they're written without parentheses. So the body
of a func is the body of the "most curried" function:
func foo(x:int) -> (y:int) -> int {
// This is the body of the function that takes 'y'.
// It returns an int.
}
func bar(x:int) -> ((y:int) -> int) {
// This is the body of the function that takes 'x'.
// It returns a functon of type (y:int) -> int.
}
Swift SVN r993
that LLVM supports. The standard library still only exports float and double,
but the swift core should be more general. Yay for PPC128 :)
Swift SVN r973
Also use the new getAdvancedLoc() method instead of hacking
on SMLoc directly.
Also fix the warning/note/error methods to forward through ASTContext
instead of being replicated everywhere.
Swift SVN r750
diagnostics over to it.
There are a few differences between this diagnostic engine and Clang's
engine:
- Diagnostics are specified by a .def file (Diagnostics.def), rather
than via tblgen, which drastically simplifies the build and makes
code completion work when you add a new diagnostic.
- Calls to the "diagnose()" method are safely typed based on the
argument types specified in the .def file, so it's harder to write a
diagnostic whose expected arguments (in the string) and whose actual
arguments (in the code) don't match.
- It uses variadic templates, so it hangs with the cool kids.
Swift SVN r734
