Instead of immediately creating closures for local function declarations and treating them directly as capturable values, break function captures down and transitively capture the storage necessary to invoke the captured functions. Change the way SILGen emits calls to closures and local functions so that it treats the capture list as the first curry level of an invocation, so that full applications of closure literals or nested functions don't require a partial apply at all. This allows references among local functions with captures to work within the existing confines of partial_apply, and also has the nice benefit that circular references would work without creating reference cycles (though Sema unfortunately rejects them; something we arguably ought to fix.)
This fixes rdar://problem/11266246 and improves codegen of local functions. Full applications of functions, or immediate applications of closure literals like { }(), now never need to allocate a closure.
Swift SVN r28112
In addition to being better for performance in these cases, this disables the "self."
requirement in these blocks. {}() constructs are often used to work around statements
that are not exprs in Swift, so they are reasonably important.
Fixing this takes a couple of pieces working together:
- Add a new 'extraFunctionAttrs' map to the ConstraintSystem for solution
invariant function attributes that are inferred (like @noescape).
- Teach constraint simplification of function applications to propagate
@noescape between unified function types.
- Teach CSGen of ApplyExprs to mark the callee functiontype as noescape
when it is obviously a ClosureExpr.
This is a very limited fix in some ways: you could argue that ApplyExpr should
*always* mark its callee as noescape. However, doing so would just introduce a
ton of function conversions to remove it again, so we don't do that.
Swift SVN r27723
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
rdar://problem/17198298
- Allow 'static' in protocol property and func requirements, but not 'class'.
- Allow 'static' methods in classes - they are 'class final'.
- Only allow 'class' methods in classes (or extensions of classes)
- Remove now unneeded diagnostics related to finding 'static' in previously banned places.
- Update relevant diagnostics to make the new rules clear.
Swift SVN r24260
Now the SILLinkage for functions and global variables is according to the swift visibility (private, internal or public).
In addition, the fact whether a function or global variable is considered as fragile, is kept in a separate flag at SIL level.
Previously the linkage was used for this (e.g. no inlining of less visible functions to more visible functions). But it had no effect,
because everything was public anyway.
For now this isFragile-flag is set for public transparent functions and for everything if a module is compiled with -sil-serialize-all,
i.e. for the stdlib.
For details see <rdar://problem/18201785> Set SILLinkage correctly and better handling of fragile functions.
The benefits of this change are:
*) Enable to eliminate unused private and internal functions
*) It should be possible now to use private in the stdlib
*) The symbol linkage is as one would expect (previously almost all symbols were public).
More details:
Specializations from fragile functions (e.g. from the stdlib) now get linkonce_odr,default
linkage instead of linkonce_odr,hidden, i.e. they have public visibility.
The reason is: if such a function is called from another fragile function (in the same module),
then it has to be visible from a third module, in case the fragile caller is inlined but not
the specialized function.
I had to update lots of test files, because many CHECK-LABEL lines include the linkage, which has changed.
The -sil-serialize-all option is now handled at SILGen and not at the Serializer.
This means that test files in sil format which are compiled with -sil-serialize-all
must have the [fragile] attribute set for all functions and globals.
The -disable-access-control option doesn't help anymore if the accessed module is not compiled
with -sil-serialize-all, because the linker will complain about unresolved symbols.
A final note: I tried to consider all the implications of this change, but it's not a low-risk change.
If you have any comments, please let me know.
Swift SVN r22215
