These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
This reverts r8624 and compensates by passing the TU to the SILModule printer when needed.
This addresses concerns that Jordan and Sean had raised.
Swift SVN r8678
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
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
for func decls that capture globals defined in the current file. For example, for:
var x : Int
func foo() {
print(x)
}
x = 15
We now silgen to:
sil internal @top_level_code : $() -> () {
bb0:
%0 = global_addr #x : $*Int64 // user: %1
%1 = mark_uninitialized %0 : $*Int64 // users: %7, %2
mark_function_escape %1 : $*Int64
// function_ref swift.Int64._convertFromBuiltinIntegerLiteral (swift.Int64.metatype)(val : Builtin.Int128) -> swift.Int64
%3 = function_ref @_TSi33_convertFromBuiltinIntegerLiteralfMSiFT3valBi128__Si : $[thin] ((val : Builtin.Int128), Int64.metatype) -> Int64 // user: %6
%4 = metatype $Int64.metatype // user: %6
%5 = integer_literal $Builtin.Int128, 15 // user: %6
%6 = apply [transparent] %3(%5, %4) : $[thin] ((val : Builtin.Int128), Int64.metatype) -> Int64 // user: %7
assign %6 to %1 : $*Int64
%8 = tuple () // user: %9
return %8 : $()
}
which will allow definite initialization to diagnose the error.
Note that we don't currently handle uses in constructors, like:
class frank {
constructor() {
print(x)
}
}
... because the capture list is only stored for FuncDecls, not for AbstractFunction's. It should be hoisted up at some point.
Swift SVN r8188
Instead of eagerly emitting currying thunks as external symbols, emit them as needed and give them hidden ODR linkage. Partial function/method applications are probably a minority of usages, so this should reduce code volume overall. Also, for ObjC classes from the framework and for protocol methods, I don't think we want to eagerly emit thunks.
Swift SVN r8123
Lazily-generated currying thunks will require the same IR-level linkonce_odr linkage as clang thunks currently do, so generalize the name of the existing SIL-level linkage specifier 'clang_thunk'.
Swift SVN r8122
In SILGenApply, if we have a partially-applied invocation of a class method, make a call to a currying thunk instead of trying to perform dynamic dispatch in-line. Emit the class dynamic dispatch instead as part of the currying thunk itself, and close over the dynamic method pointer as part of the curried closure context.
Swift SVN r8076
Among other things this enables mangled names for tuples.
This adds a pointer to the DeclContext to SILFunction and which is used
to provide the necessary context to the Mangler.
Fixes rdar://problem/14808764 and rdar://problem/14813658.
Swift SVN r8070
SILGen learned how to forward archetypes for generic class constructors, and we can reuse this knowledge to finally implement curry thunks for generic functions.
Generic methods still pose a problem because we can't return a value of polymorphic type, so we'd need to hoist polymorphic parameters to the outermost uncurry level during SIL function type canonicalization even at uncurry level zero.
Swift SVN r8054
ConstructorDecl::getBody() and DestructorDecl::getBody() return 'BraceStmt *'.
After changing the AST representation for functions, FuncDecl::getBody() will
return 'BraceStmt *' and FuncDecl::getFuncExpr() will be gone.
Swift SVN r8050
Struct instance methods don't need to capture any special dynamic dispatch behavior, so they can use the same codegen path as standalone curried functions. Fixes <rdar://problem/14687373>.
Swift SVN r8049
functions should be serialized.
Transparent is added as a 1-bit field. In SILGen, we set SILFunction's
transparent attribute according to the attribute of the ValueDecl.
Swift SVN r7882
Auto generated location should not be a separate location kind since
we might have different kinds of auto generated locations (ex: cleanup,
return). Even though the kind info might not be necessary for diagnostics or
debug info, it allows us to better use type system, for example, only pass
CleanupLocation where expected.
Swift SVN r7816
I've decided to keep only the location of the scope AST node that corresponds to the cleanup. (Currently, there is no user that needs the originator expression, which caused the cleanup. So keeping things simple.)
Added the cleanup location to the Scope and JumpDest classes, which gets assigned on construction of those. The Scope's and JumpDest locations are used when we emit the cleanup instructions.
We now give better location info for 2 existing tests for definitive initialization.
(+ Rather sparse testing of all this.)
Swift SVN r7764
We mark the branch instructions leading into single epilog code with ReturnLocation/ImplicitReturnLocation. If SIL Gen simplifies the code and merges the code representing the return into the epilog block, the terminator of the epilog block (the ReturnInst) will have the return location info on it. Otherwise, the ReturnInst has the RegularLocation, which represents the enclosing FunctionExpr or Constructor/Destructor Decls.
(I've discussed dropping the optimization from SILGen, and keeping the epilog code canonical, with Adrian; but he said that there might not be any wins in doing so, so keeping it for now.)
Added AutoGeneratedLocation to represent segments of code generated by SILGen. This will be used for thunks and other auto-generated segments.
Swift SVN r7634
Generate union constructors as SIL functions using the new 'union' instruction. Change UnionTypeInfo::emitInjectionFunctionBody into UnionTypeInfo::emitInjection, which emits the union value to an explosion rather than emitting the scalar return directly, and use it to implement IRGen lowering of the 'union' instruction.
This breaks a few serialization tests because of mangler bugs handling generic unions, which I'll fix next.
Swift SVN r7559
