For every global pattern binding, emit a lazy initializer token and function that initializes the global variables in that binding. For each of those vars, create an accessor that Builtin.once's the lazy initializer before producing the address. Hide this all behind a switch till the surrounding serialization and IRGen infrastructure catches up.
Swift SVN r10511
In SILGen, when we emit the enum external definition, emit the methods in addition to the case constructors for the enum. Make sure they get thunk linkage.
Swift SVN r10017
Ideally this wouldn't be necessary, but the type substitution APIs required by generic specialization and SIL verification currently require a Module* pointer, and it's obnoxious to have to pass it down separately everywhere it's needed. Longer-term the reliance on Modules for type substitution might be able to go away.
Swift SVN r9866
Anywhere that assumes a single input file per TU now has to do so explicitly.
Parsing still puts all files in a single SourceFile instance; that's next on
the list.
There are a lot of issues still to go, but the design is now in place.
Swift SVN r9669
We already know how to call external functions in SILGen, why reimplement all that in IRGen? Instead of representing the thunk operation as a SIL instruction, let's just emit the thunk using existing SILGen machinery. Fixes <rdar://problem/14097136>.
Swift SVN r9576
Once we have multiple SourceFiles in a TranslationUnit, it no longer makes
sense to say "only SILGen decls starting from element N" without specifying
which source file you mean.
Also, clarify ownership by having performSILGeneration return a unique_ptr
instead of just a bare pointer.
Swift SVN r9112
Right now this is just an extra layer of indirection for the decls,
operators, and imports in a TU, but it's the first step towards compiling
multiple source files at once without pretending they're all in a single
file. This is important for the "implicit visibility" feature, where
declarations from other source files in the same module are accessible
from the file currently being compiled.
Swift SVN r9072
Make ApplyInst and PartialApplyInst directly take substitutions for generic functions instead of trying to stage out substitutions separately. The legacy reasons for doing this are gone.
Swift SVN r8747
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
