This paves the way for having a Swift module importer. The eventual goal
here is to eliminate all explicit uses of the Clang module loader, but
I'm not going to push too hard on that for now.
Swift SVN r5092
We will handle Swift-function-to-ObjC-block bridging in SILGen as part of general Cocoa-to-Swift type bridging. Temporarily disable building swiftAppKit and tests that exercise block bridging until the new implementation lands.
Swift SVN r5090
When an IdentifierType is resolved to a local type in the same decl context, we weren't setting the parent type correctly, causing blowups in type checking when a local type didn't have its generic parameters from context available. Set the parent type to the DeclaredTypeInContext of the type to which we resolved an unqualified lookup. Fixes <rdar://problem/12895793>.
Swift SVN r5084
Keep track of external definitions as they are created by broadcasting
them through a mutation listener interface. At name binding time, we
just cache them. When a type checker is alive, it immediately performs
any additional operations necessary on those types (e.g., declaring
implicit constructors).
This also eliminates some O(N^2) behavior in the type checker as well,
because we don't have to walk through all of the module imports to
find the external definitions. We just keep a single list in the
ASTContext along with our place in the list.
Fixes <rdar://problem/13769497>.
Swift SVN r5032
Some SIL operations only make sense on no-context functions, such as creating a context for a function with "curry" or specializing. We're going to need this concept in Swift for interop with C functions too, so I'm adding it to the Swift type system. This patch only adds the attribute bit to function types without exposing the attribute to Swift syntax or providing any means in Swift to produce values of thin function type or to type-check them.
Swift SVN r4416
For the demo we'll import block types as [objc_block] (A) -> B types in Swift and rely on the type attribute to handle bridging Swift closures to ObjC blocks.
Swift SVN r3895
Archetypes and projected existentials have the type %swift.opaque* and not i8*, so I need a corresponding SIL type to be able to model the ProjectExistential operation. We might also end up needing the builtin type for other low-level things down the line.
Swift SVN r3793
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
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
We'll want a superclass pointer on ClassType and BoundGenericClassType,
and this also makes it easier to detect both kinds of class type.
Swift SVN r3061
Finishes off <rdar://problem/12337042>.
Also, fix constraint application so that test/Constraints/closures.swift
doesn't explode with the above fix.
Swift SVN r2888
checker. There are a few related sets of changes here:
- Generic parameter lists have a link to their "outer" generic
parameter lists, so its easy to establish the full generic context
of an entity.
- Bound and unbound generic types now carry a parent type, so that
we distinguish between, e.g., X<Int>.Inner<Int> and
X<Double>.Inner<Int>. Deduction, substitution, canonicalization,
etc. cope with the parent type.
- Opening of polymorphic types now handles multiple levels of
generic parameters when needed (e.g., when we're substituting into
the base).
Note that the generics module implied by this representation restricts
what one can do with requirements clauses in nested generics. For
example, one cannot add requirements to outer generic parameters or
their associated types, e.g., this is ill-formed:
struct X<T : Range> {
func f<U requires T.Element : Range>() {}
}
The restriction has some precedent (e.g., in C#), but could be
loosened by rearchitecting how we handle archetypes in nested
generics. The current approach is more straightforward.
Swift SVN r2568
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
member of a oneof/struct/class/extension to support types nested
within generic classes, e.g., Vector<Int>.ElementRange.
Most importantly, nominal types are no longer inherently canonical. A
nominal type refers to both a particular nominal type declaration as
well as its parent, which may be non-canonical and will vary. For
example, the variance in the parent makes Vector<Int>.ElementRange and
Vector<Float>.ElementRange different types.
Introduce deduction and substitution for nominal types. Deduction is
particular interesting because we actually do allow deduction of T
when comparing X<T>.Inner and X<Int>.Inner, because (unlike C++) there
is no specialization to thwart us.
Swift SVN r2507
analysis for patterns.
Major changes:
1. We no longer try to compute the types of functions in the parser.
2. The type of a function always matches the type of the argument patterns.
3. Every FuncDecl now has a corresponding FuncExpr; that FuncExpr might not
have a body, though.
4. We now use a new class "ExprHandle" so that both a pattern and a type
can hold a reference to the same expression.
Hopefully this will be a more reasonable foundation for further changes to
how we compute the types of FuncDecls in generics and for the implementation
of type location information.
Swift SVN r2370
the various NominalDecl subclasses into a single NominalType* member
in NominalDecl. Use it to make TypeDecl::getDeclaredType() more
efficient/simpler, and simplify the ProtocolDecl/ProtocolType
interaction along the way.
No functionality change.
Swift SVN r2298
protocol conformance types, e.g., 'protocol<P, Q>'. A few things
people *might* want to scream about, or at least scrutinize:
- The parsing of the '<' and '>' is odd, because '<' and '>' aren't
tokens, but are part of the operator grammar. Neither are '>>',
'>>>', '<>', etc., which also come up and need to be parsed
here. Rather than turning anything starting with '<' or '>' into a
different kind of token, I instead parse the initial '<' or '>'
from an operator token and leave the rest of the token as the
remaining operator.
- The canonical form of a protocol-composition type is minimized by
removing any protocols in the list that were inherited by other
protocols in the list, then sorting it. If a singleton list is
left, then the canonical type is simply that protocol type.
- It's a little unfortunate that we now have two existential types
in the system (ProtocolType and ProtocolCompositionType), because
many places will have to check both. Once ProtocolCompositionTypes
are working, we should consider whether it makes sense to remove
ProtocolType.
Still to come: name lookup, coercions.
Swift SVN r2066
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
generic over the type of the base. By "generic" I mean that it's
looked up by prepending the word "Slice" to the name of the base
type.
Swift SVN r1464
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
type with one or more elements of dependent type. Previously, an
expression such as (x, 5) would have the (unstructured) dependent
type, limiting our ability to type-check the subexpression 'x'
early. Now, if 'x' has type 'int' (for example), this expression will
now have the type (int, <<unstructured dependent type>>).
Extend coercion of a tuple to tuple type to handle coercion to
(structured) dependent tuple types, coercing element-by-element. This
code is very lightly tested and may still need to be restructured.
Swift SVN r1294
