Instead, pass a LazyResolver down through name lookup, and type-check
things on demand. Most of the churn here is simply passing that extra
LazyResolver parameter through.
This doesn't actually work yet; the later commits will fix this.
Swift SVN r8643
Create a local box for byref arguments that can be closed over. The box receives the value of the byref at function entry, and the value in the box at function exit is written back to the byref. This will allow us to eliminate the no-capture restriction on byrefs, allowing them to be used in auto closures and other HOFs, and doing the right thing in the 99% case where closures are effectively nocapture without requiring user annotation. <rdar://problem/14732389>
There are a couple of loose ends:
- The type-checker can lose its restriction on byref captures. I'll do that next.
- Debug info needs to learn how to represent local byref boxes. Adrian is better qualified to decide how to do that.
- Byref shadow copies completely defeat the copy-on-write optimization for String, making append sequences ridiculously slow. Memory promotion needs to learn to eliminate shadow copies completely when it promotes away byref boxes in order to solve this regression.
Swift SVN r8630
This mirrors the behavior of project_existential and simplifies some special cases in SILGen. It unfortunately makes dynamic_lookup sequences a bit noisier because of the need to explicitly cast the projection from DynamicLookup.Self to Builtin.ObjCPointer, but I think this modeling is more solid and will fit better with my planned redesign of archetype_method/protocol_method.
Swift SVN r8572
This contains one significant difference from the design:
previously, you declared:
var [weak] x : NSObject
and the type of 'x' was implicitly Optional. This change
in the formal type proved problematic in a number of ways,
and Joe made the excellent suggestion to eliminate it:
so now you have to declare:
var [weak] x : NSObject?
and [weak] is just a kind of modifier on the storage of the
optional value. You could argue that this is somewhat
pedantic, but I think it restores a lot of consistency to
the model.
Swift SVN r8538
Introduce an EnumCaseDecl for source fidelity to track the 'case' location and ordering of EnumElementDecls. Parse a comma-separated list of EnumElementDecls after a 'case' token.
Swift SVN r8509
Improve the type checker to create implicit DestructorDecls, tighten the
assertion in ImplicitReturnLocation::getImplicitReturnLoc(), and add a verifier
check that a class in a type checked AST always has exactly one destructor.
SILGen used to generate a destructor if the class does not have a
DestructorDecl. SILGen used to put the ClassDecl inside the SILLocation for
the destructor SIL code. This is not a very clean solution: in this case
ImplicitReturnLocation SILLocations contain ClassDecl, which is surprising.
rdar://14970972 Implicit destructors should have AST nodes
Swift SVN r8498
When a given class definition has no constructors, the parser was
introducing an implicit-declared default constructor in the class. The
type checker ignored it. SILGen creating something that was completely
broken. Remove all of that and fix the fallout.
Swift SVN r8432
When we import an Objective-C init method into Swift as a constructor,
the Clang importer currently synthesizes both a +alloc call (used by
the allocating constructor) and a body that forwards to the
corresponding init method. Eliminate the body and stop emitting an
initializing constructor at all: instead, the allocating constructor
will invoke the init method through objc_msgSend.
Swift SVN r8420
Now that all [objc] constructors have a suitable "init" selector, emit
an Objective-C thunk for the initializing constructor (not the
allocating constructor!) with that selector, and make sure it shows up
in the Objective-C metadata.
With this, we can write a Swift constructor "constructor()" to
override "-init"; see the change to ListMaker that exercises this.
Joe or John: I'd love a review of these.
Swift SVN r8373
Implement the new rules for mapping between selector names and
constructors. The selector for a given constructor is formed by
looking at the names of the constructor parameters:
* For the first parameter, prepend "init" to the parameter name and
uppercase the first letter of the parameter name. Append ':' if
there are > 1 parameters or the parameter has non-empty-tuple type.
* For the remaining parameters, the name of each parameter followed
by ':'.
When a parameter doesn't exist, assume that the parameter name is the
empty string.
And, because I failed to commit it separately, support selector-style
declarations of constructor parameters so that we can actually write
constructors nicely, e.g.:
// selector is initWithFoo:bar:
constructor withFoo(foo : Foo) bar(bar : Bar) { ... }
Swift SVN r8361
AnyFunctionRef is a universal function reference that can wrap all AST nodes
that represent functions and exposes a common interface to them. Use it in two
places in SIL where CapturingExpr was used previously.
AnyFunctionRef allows further simplifications in other places, but these will
be done separately.
Swift SVN r8239
We want the argument generator functions to be treated as transparent iff the "parent" function is transparent. There is no need to special case it in isTransparent because the SILDeclRef contains the :parent" Decl, and the first check will just work for us automatically.
Do make sure that the isTransparent is consulted when the apply instruction is created.
Swift SVN r8224
If a struct has [unowned] fields and an implicit elementwise constructor, then the constructor receives a strong reference argument corresponding to the unowned field, and we have to introduce that conversion as part of the construction.
Swift SVN r8207
Teach a BoundGenericType to compute its own substitutions, which
allows AST clients to create new bound generic types without the aid
of the type checker.
This eliminates the TypeChecker::validateTypeSimple() abomination as
well as the need for the BoundGenericType AST validation step. There
is still more cleanup to do in this area.
Note that BoundGenericType::getSubstitutions() now accepts a module
parameter, which is the place from which we will look for
conformances. This is a baby step toward properly modeling the
conformances as part of the bound generic type, and is nowhere near
complete.
Swift SVN r8193
