We were failing to capture generic parameters from closure contexts that themselves capture generic parameters from context. This fixes <rdar://problem/15417783>. While we're here, eliminate some unnecessary splitting of 'ClosureExpr' and 'AutoClosureExpr' in the SILDeclRef::Loc PointerUnion; we can just use their base class AbstractClosureExpr in the PointerUnion.
Swift SVN r10031
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
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
Attribute [transparent] on extensions should apply to all members(functions, properties) of that extension.
Addresses radar://15035271.
Swift SVN r8735
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
Doug pointed out that 'isObjC' incorrectly excludes C functions, for which we'll also need to be able to independently reference Swift and foreign entries.
Swift SVN r8669
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
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
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
global variables used by functions in the capture list as well.
SILGen and other things that don't care about these (i.e., all
current current clients) filter the list to get what they want.
This is needed for future definite init improvements, and unblocked
by Doug's patch in r8039 (thanks! :)
No functionality change.
Swift SVN r8045
Thunks above the natural uncurry level of a function should always be emitted with standalone function CC instead of method or foreign CC. Partially addresses <rdar://problem/14687373>, but we still don't emit thunks for struct instance methods.
Swift SVN r8043
This was not likely an error-free change. Where you see problems
please correct them. This went through a fairly tedious audit
before committing, but comments might have been changed incorrectly,
not changed at all, etc.
Swift SVN r7631
I’ve added it without understanding the full consequences. If a variant of this is added, it
should take a list of values as the argument. Currently, there is no use for it, so just remove it.
Swift SVN r7238
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
"SILConstant" doesn't really describe its role in SIL anymore, which is to provide a reference to a Swift declaration in a SIL instruction, such as a method or nominal type field.
Swift SVN r6559
In the resilience model for default arguments, the presence of a
default argument is API, but its specific value is not. Thus, the
actual default argument values can evolve over time. To implement
this, for each default argument, we emit a function that
takes no arguments and produces the default value for that
argument. The caller will then call that function to form the default
argument.
This commit emits these functions for each default argument, even
though they are not currently being called. This is part of
<rdar://problem/11561185>.
We'll probably want a different calling convention for these functions
that preserves all registers, since they will often end up being very
trivial functions.
Swift SVN r6260
In this case "naturalUncurryLevel" *might* be uninitialized. I'd prefer
that this code be structured with a switch to prove that all cases
are covered, but that might not be the cleanest solution. I'll
leave that for Joe to decide.
Swift SVN r5565
Add class-bound versions of archetype conversion and existential creation/projection/conversion instructions. Since class-bound generics aren't address-only these instruction variants don't need to indirect through addresses.
Swift SVN r5554
This frees up an extra bit in SILType, which we can expose to LLVM through
PointerLikeTypeTraits. Use this bit in a PointerUnion, which allows simplifying
ValueBase, which happened to be the last use of the isInvalid() state.
Swift SVN r5218
Emit thunks for [objc] class methods and properties as SILFunctions, using SILGen's OwnershipConventions. This will help kill some redundant ownership code in IRGen, and will allow msgSend thunks to handle string and block bridging. IRGen doesn't actually codegen the thunks yet; that will require teaching IRGenSILFunction how to be AbstractCC-aware, so for now, we just reemit the thunks using the old IRGen code.
Swift SVN r5168
Sever the last load-bearing link between SILFunction and SILConstant by naming SILFunctions with their mangled symbol names. Move the core of the mangler up to SIL, and teach SILGen how to use it to mangle a SILConstant.
Swift SVN r4964
Change the destroying destructor entry point ABI to take 'this' as the appropriate type instead of as %swift.refcounted. Emit the deallocating destructor in IRGen when we see the ClassDecl, not when we see the SILFunction for the destructor. This frees us from having to worry about whether a SILFunction came from a destructor decl. We won't be able to reconstruct that once SILFunctions are pre-mangled.
While we're here, repaint some bikesheds so it's clearer that SIL and SILGen work with the destroying destructor.
Swift SVN r4908
Move AbstractCC into SILType and make it an attribute of SILTypes for functions. Add a ConvertCCInst to represent calling convention conversions. Give SILFunctions a linkage attribute. Add logic to SILGen to calculate these attributes for SILConstants based on their attached decls.
IRGen doesn't use these new attributes yet. I'll hook that up when I move mangling over.
Swift SVN r4886
Replace 'constant_ref' with 'function_ref', which references a SILFunction directly, and 'global_addr', which references a global variable VarDecl. Get rid of the SILConstant-to-SILFunction mapping in SILModule and replace it with an ilist of SILFunctions. Allow SILFunctions to be 'external' by not having any blocks in their body.
For now, SILFunctions still carry around their SILConstant "name", because name mangling and IRGen still rely on access to the original decl in order to recover IRGen information, which unfortunately leaves IRGen's CodeRefs in a gross, awkward intermediate state. Lifting mangling, AbstractCC, and other linkage attributes to SIL should clear up this up.
Swift SVN r4865
